Doom Wiki:Central Processing


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.

Archived discussions

Doomsday Wiki[edit]

The Doomsday Engine Wiki ( is no more, replaced by a Doomsday Engine Manual ( It's not just an address change, it's the entire thing rewritten from scratch with a different organization, so there's no 1-to-1 mapping between DEW articles and DEM articles. That means we have to find and update every links on our wiki. --Gez (talk) 13:39, 13 December 2018 (CST)

Sounds like a plan. Make it so. :) --Xymph (talk) 03:01, 15 December 2018 (CST)

Update: I believe I have fixed this.  Please somebody check my interwiki changes, which affect WikiNode and the template, probably the two most important cases.

I'm far from an expert but it seems our IRC conversation was correct: the number of existing links was small to begin with.  Hopefully that changes someday; there are certainly people in the community who considered it the best port, and even modded for it.    Ryan W (living fossil) 09:19, 5 April 2019 (CDT)


Happy New Year everybody! --Quasar (talk) 00:13, 1 January 2019 (CST)


Hi all, I see you managed to pull script for competn demos. Very nice! :) If you need some help in any kind I'll be pleased to help and give you info how to get info. I can even provide direct sql reads to database if anyone is interested for example to show only current records per wad/map/etc. --Fx

Hi, not sure why you think "pull script" applies to demos tables. To my knowledge, they were all created/updated manually over the years.
Anyway, scripting XymphBot updates of that information is on my to-do list and received prior discussion already (and for DSADA too). Your kind offer of direct SQL access (or just a, say, weekly export that I can load and process locally) would ease one major part of that project considerably. But currently two non-wiki projects serve as my time sink ;-) so it will be quite a long time before I would be able to turn my attention to this project. --Xymph (talk) 05:05, 23 January 2019 (CST)
I was thinking about "External links" category where you made auto linking like this: * MAP01 demos from the Compet-n database: UV speed • NM speed • UV max • NM100S • UV -fast • UV -respawn • UV Tyson • UV pacifist which is rather cool. There is incoming log file that can be parsed but there can be multiple wrong uploads. In the end query to latest record is possible as I have column just for that (current_record). Anyway, if I could help you somehow, feel free to ask whatever is on your mind. --Fx (talk) 18:02, 23 January 2019 (CST)
Ah yes, those IDs are part of XymphBot's .ini system and the links are generated by the demolinkBot script. Thanks for the offer, once my plate is sufficiently cleared of ongoing and unfinished projects (wiki and otherwise), I intend to return to this topic. --Xymph (talk) 13:02, 23 January 2019 (CST)

Influence of certain maps[edit]

Would anyone be in favour of adding more info to certain map pages showing which other maps they have inspired as I have done for MAP24: Post Mortem? I think it would be good addition and would prevent the map pages becoming just a bunch of walkthroughs and map stats.

Off the top of my head other ones that could be added are:

Let me know if there are any more examples of this. —The preceding unsigned comment was added by Rootof2 (talkcontribs) .

Could be interesting. Only issue is maybe making sure we don't stray too far into speculation. An example I know of right off the bat is MAP21: Slayer (The Plutonia Experiment), which is obviously a "hard type" version of MAP11 from Doom II. Then in turn, many Plutonia 2 maps expand directly on the theme of a map from Plutonia. Sometimes this is mentioned and other times it is not. --Quasar (talk) 11:19, 31 January 2019 (CST)
I agree we should not stray too far into speculation but I think with the examples you and I have provided direct comparisons between the maps can be made. I think overall though it would provide valuable information to the reader about the history of mapmaking and how it has changed over time. --Rootof2 (talk) 11:30, 31 January 2019 (CST)
I like this.  Any topic benefits IMO by showing interconnections between individual events, and mappers are always saying they study the best of others' releases to learn from them.
Some speculation may be unavoidable, especially for older maps where the development documentation is gone, and there wasn't this community compulsion to give everyone proper credit like there is now.  Moreover, creative people may imitate without even realizing it, because the prior author's work affected them so much, and some of course try to keep it secret, thinking you won't download otherwise.  I agree with Quasar that it can get out of hand (our "music inspirations" threads/sections were such a lightning rod that eventually admins just started erasing content), so you'll need to be patient and perhaps try not to attract attention  :>  until you have a sense of where the balance lies.  FWIW, Ryan W (living fossil) 14:13, 1 February 2019 (CST)

OpenGraphMeta SEO additions[edit]

I've added some new features to our customized OpenGraphMeta extension:

  • Articles now have JSON-LD metadata - supposed to be good for SEO.
    • Also ties the wiki to corresponding social media profile(s).
  • Can define custom meta keywords on the page (will probably make a template for this and do some limited deployment eventually).
    • The default meta keywords are now defined on the wiki (message seo-default-keywords) instead of inside our LocalSettings.php file.
  • Support for meta itemprop tags in the page header (of limited use thus far).

Most of the code for this stuff came from Curse, which I found out open sourced their stuff under GPL not very long ago. --Quasar (talk) 03:07, 28 March 2019 (CDT)

Category for maps with extra monsters in co-op?[edit]

A little while ago a category was made for maps with a deathmatch area separate from everything else. I thought maybe if it's worth having that then it might be worth having this too. Is there an easy way of finding maps that fit the criteria? - SiFi270 (talk) 11:00, 28 March 2019 (CDT)

If there is support for this idea, then I could write a XymphBot script to accomplish it. --Xymph (talk) 09:52, 31 March 2019 (CDT)
Unlike some recent proposals, this one admits to an algorithm, so I'd support XymphBot carrying it out if resources allow.  I can see it being relevant to co-op devotees (FWIW given I'm not one, except in Gauntlet).    Ryan W (living fossil) 10:49, 31 March 2019 (CDT)
I've added the functionality to DMMPST to list the things where extra items occur in coop compared to single-player. This is generalized so the list(s) can be produced not just for monsters but also weapons, ammo, items, etc. The list(s) in turn will be used in a XymphBot script that modifies map articles to add the new category.
But before I move on to that, this raises the question whether an additional category, e.g. "Levels with extra equipment in co-op", would be worth adding too? MAP01: Outpost (Memento Mori II) has some extra monsters but also an extra shotgun. MAP17: No One (Memento Mori II) has heaps of extra monsters, weapons/ammo, health & armor.
Caveat is that on maps with a separate deathmatch arena with piles of stuff, such as MAP07: Frustration (Memento Mori II), DMMPST cannot determine which items are extra specifically to coop. (The DM things table on such articles was generated from a separate, specially cropped version of the WAD/map.)
And the second question raised is whether the extra item counts should actually be listed in a table in the article? And if so, where/how? --Xymph (talk) 16:33, 9 May 2019 (CDT)
IMO the equipment category is good; if we're already adding the monster category, we might as well be thorough (easy for me to say of course  :>
I'm mightily undecided about tables.  In theory, presenting more data is helpful, but based on previous thing table discussions, there seems to be a tipping point where the layout becomes cumbersome to read.  One could imagine alternate approaches, e.g. a co-op strategy subsection following the deathmatch part, where the important pickups would be pointed out within that narrative.  OTOH contributors aren't exactly lining up to do such writing and testing, and if they did, the table wouldn't prevent it.
This may be recentism, but my impression is that people just play with item respawning anyway, because they want to be able to choose any map with co-op starts, not just the tiny subset where co-op is integrated into the entire design.  HTH.  Ryan W (living fossil) 08:53, 19 May 2019 (CDT)

← ← ← ←
This little project is completed, except of course for map articles not yet covered by .ini files because help is needed. --Xymph (talk) 06:08, 10 June 2019 (CDT)

Hell Guard editor[edit]

Hi! I'm Shotgun2016, I just joined, and I religiously play DOOM 2016. I edited the Hell Guard page and many others before joining, and I'm looking for some feedback. I've took an oath to log in at least once a week, so I'll reply quickly to any feedback. — —The preceding unsigned comment was added by Shotgun2016 (talkcontribs) .

Attribution question[edit]

Moved from here. — Ryan W (living fossil) 16:33, 11 April 2019 (CDT)

I am a new user, and edited articles before creating an account, such as the Hell Guard. How do I identify these as being my works? —The preceding unsigned comment was added by Shotgun2016 (talkcontribs) .

You could edit the unregistered "user page" to state this, with a link to your registered name.  At least, that's been done before (I can think of more drastic approaches requiring admin assistance, but I have no idea if they would work, or be acceptable to the community).
Remember that the wiki database already considers you identified by your IP address.  It was your choice whether to create an account first, you decided not to, and the software respects that decision for increased transparency.  HTH.  Ryan W (living fossil) 10:24, 12 April 2019 (CDT)

Thanks. I apologize for my amateur wiki abilities; I hope to compensate for this by having a good knowledge of DOOM 2016. --Shotgun2016

latest wiki dump available[edit]

I do this roughly annually, this is the third dump. -- Shambler (talk) 07:52, 15 April 2019 (CDT)

FlaggedRevs configuration change proposal[edit]

Dissatisfaction with the settings for autopromotion have been expressed since go-live back in 2011 but I never really figured out what to do with it. My current suggestion: cut the page edit requirements roughly in half:

Variable Current Target
edits 250 125
totalContentEdits 300 150
totalCheckedEdits 200 100
benchmarks 14 7

These feel like they give more than enough time, along with the other requirements like using unique edit summaries, having a max 3% rollback/revert rate, etc, to determine if somebody is trustable enough to get autochecks. --Quasar (talk) 21:53, 5 May 2019 (CDT)

To see what all the variables mean, go here and search for wgFlaggedRevsAutopromote.
Established community members should never be obstructed by this, because any admin can confer the permissions manually.  I promoted three people in 2012 to address the backlog, with zero drama (though none had time to help either sadly).  I can't judge in this case, as I don't recall any previous interaction, although one more contributor who knows disassembly can't be bad!  :>
Still thinking about whether a config change is worth the effort.    Ryan W (living fossil) 17:45, 6 May 2019 (CDT)
There is no effort, it's literally 4 lines to add in our LocalSettings.php. What I need ultimately is your opinion on the reasonableness of the amount of edits required. Manual promotion is neither really "here" nor "there" with respect to changing this. If what you're saying is that you'd prefer there be no autopromotion, then we can just disable it. But then people have to be on top of determining who gets it and when at all times. Currently I don't see that has been happening. If 2012 was the last time it was used, it's definitely not. --Quasar (talk) 09:17, 7 May 2019 (CDT)
I've opposed autopromotion in the past, which IIRC was on two grounds.  (1) User rights changed systematically without consensus or even announcement.  I suppose that's water under the bridge, and low overall participation is the most pressing issue, so having more (potential) reviewers can only help us.  (2) The filter can be, and has been, fooled by edits that are borderline helpful but also self-aggrandizing, plagiarized, full of markup errors, etc.  This is exacerbated by reviewers who interrupt their current task to "complete" the edit rather than reverting, thus decreasing the revert percentage.  In hindsight, however, such situations are too rare to build process around.
Your argument on IRC about the "fairness" of an automatic approach is persuasive — many community members are wary of subjectivity and groupthink in admin decisions — and you may have convinced me.    Ryan W (living fossil) 22:45, 7 May 2019 (CDT)
What is the objective of this system? Curb vandalism so it doesn't show up automatically? Have editors fact check stuff added in new edits? Have editors review the style of new edits? A mixture of the three? If it's mostly the first one, then the requirements can be cut even more. Also, someone who is not familiar with how this site operates might think that edits are rejected often and then be reluctant to contribute. --Kyano (talk) 07:24, 7 May 2019 (CDT)
All of the above. --Quasar (talk) 09:17, 7 May 2019 (CDT)
2nd is especially dangerous: it means that some edits will never be approved for fear of them being wrong. Fact checking whether Doom was made by either "id software" or "Sun Microsystems" is easy, fact checking whether a certain projectile in some obscure dehacked mod does 32 damage instead of 40 is hard. Many editors will avoid that kind of responsibility. --Kyano (talk) 16:22, 7 May 2019 (CDT)
In practice we haven't let it become that level of an obstacle. It did at one time, with trying to verify the hashes relevant to the Xbox and PS3 versions of IWADs, but we went ahead and accepted those eventually with the understanding that they are correct as far as anybody can reasonably know, and always subject to further adjustment in the future.
I feel like this is more a debate on the merits of the extension than on my suggestion to halve the autopromotion requirements. Unfortunately with regulatory things being the way they are now (SESTA, namely) that I'd prefer by far to keep things as they are right now. Having the ability to review content before it can be broadcasted out to search engines is critical at this point. --Quasar (talk) 19:54, 7 May 2019 (CDT)
(edit conflict) We don't know why so few contribute, but yes, I'd guess delays don't help.  New content is visible instantly on forums, social media, even Wikipedia where newbies are cannon fodder.  Last I looked, the most common complaint is not rejection, but an edit sitting in limbo for days until someone has time to verify all content, all technical data, all style rules, proper use of templates, disambiguation, page title conventions, cross-referencing, and oh yeah it's not spam or vandalism.  This is IMO not how the tool is meant to be used, and I plan to address that in a future proposal.    Ryan W (living fossil) 16:26, 7 May 2019 (CDT)
It's been a long time since there was a review delay that long. I check the site multiple times per day when it's physically possible to do so. If you haven't seen me do it in a day or two, it's because my work is pile driving me into the ground. Darn day jobs. --Quasar (talk) 20:10, 7 May 2019 (CDT)
TLDR: My gut feeling is that this is an improvement and should happen, but I don't have a sense of the exact number.
New users arrive with huge variation in how ready they are for a collaborative project.  User:Goyuken and User:Shidou were patient, thorough, and open to discussion from day one.  Conversely, I made about 2000 edits before I had a clue (some say I still don't).  Applying one value across the board is a judgement call as to which type of newbie should be harmed least, and whatever choice is made, edge cases will still need individual correction.
One argument for a lower number is that, in practice, harmful behavior is clear immediately rather than erupting suddenly after scores of good edits.  A high threshold alienates more good-faith newbies and increases Editor workload without really affecting security.
One argument for a higher number is that edit count is a very blunt instrument, compared to consultation with an experienced human moderator.  Therefore, if we use an algorithm, it should be somewhat conservative to prevent skilled trolls, hucksters, codependents, etc., who don't provoke immediate suspicion, from being promoted quickly.  (It already happened once at 300 edits!)  Also, permissions tend to be added to groups over time, so in effect we're evaluating users now for the more powerful "Editor" toolkit a decade hence.
Frankly I'm hoping we hear from more non-admins, who actually deal with these restrictions day after day.    Ryan W (living fossil) 22:45, 7 May 2019 (CDT)

Replace /idgames/ links with Doomworld download links[edit]

Should we consider changing all of the /idgames links to Doomworld Downloads? I assume the entire point of the Downloads is to eventually supersede /idgames entirely, and although it still seems to be a WIP it might be good to get people used to using them instead. Don't know how fast it would be to change each link though... Death Egg (talk) 18:14, 28 June 2019 (CDT)

Very, very, very slow.  It's a good question though, since the legacy pages could vanish overnight (again) and we'd like to have a plan for that.
IMO we should keep the path format because it doesn't tie us to one front end with a unique URL scheme.  The path format allows a user to download from any mirror if DW is down, or too far away to be reliable, or the user's connectivity is so slow that any Invision site is unbrowsable.  It's useful to show the reviews and readmes as advance information also, but not as a substitute for a stable file link.
Once Linguica completes the reorganizations in progress, perhaps he would be willing (or accept code from someone who is) to implement URL redirection as was done for thread IDs.  Speaking as a non-programmer, this seems reasonable because the rendered page for each file already includes download links with paths.  The crosswalk exists, it only needs inversion.  But it's his choice and if he decides not to be wiki-friendly, I would rather obfuscate reviews than create 10,000+ links which might break with the next upgrade and require manual revision (we already have too many of those).
If someone thinks I'm totally wrong and has their heart set on implementing this, may I at least suggest waiting until the domain migration?  For all we know, the URLs will change again.
Thanks to Xymph (on IRC) for helping me sound less dumb.  :>  HTH.  Ryan W (living fossil) 17:27, 29 June 2019 (CDT)
The "new" download system on Doomworld is extremely broken and has been suffering from database corruption for several years now. I do not see it becoming a reliable replacement for the old idgames database any time soon. --Quasar (talk) 20:09, 29 June 2019 (CDT)

Deletion tracking, followup[edit]

I would like to implement this proposal at last.  The plan goes beyond what we discussed IMO, so I'll post it here first:

  1. ✔ Review the current category and note any threads that look "routine", but don't edit them yet.
  2. Create category Deletion precedents, a subcategory of Talk pages without articles (which describes the database situation only, irrespective of thread content) and Article management (analogous to the resolved RFCs category).
  3. Change the archiving template to point to the new category unless an optional parameter, trivial=, is true.
  4. Update the template instructions.
  5. Wait 24 hours for the backlog to enter the new category.
  6. When a talk page has no article, and the article has never existed, don't categorize it.  This is a corner case, but if information is so incomplete or uncertain that even a sub-stub benefits from consultation, so be it.
    • EDIT:  6a. When a talk page has an article, don't categorize it.  Also a corner case but can occur, e.g. a term with multiple meanings exhumed as a redirect.  17:27, 23 October 2019 (CDT)
  7. Find uncategorized talk pages of deleted articles, and tag them with trivial=yes.  Note in passing any threads that do indeed appear substantive.
  8. Update the admin procedure for future threads.
  9. Wait 24 hours for the parent category to re-populate.
  10. Perform the tweaks in #1 and #7 (i.e. separated from the mass edit), and link them here in case anyone wants to double-check.

A thread can constitute a precedent even if the article was kept or later recreated (not sure why I didn't include that earlier).  I'll mention those cases in the documentation and categorize pages I remember, but filling in the backlog systematically is another matter; many older nominations didn't use templates at all.

Categorization tasks are never as simple as they appear!  :D  HTH.  Ryan W (living fossil) 22:17, 22 October 2019 (CDT)