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.

Thoughts on covering map WADs

[or: oh dear, Xymph wrote an essay again :-) ]

If there's one thing that stood out for me in this wiki year, it's the often prolonged debates on covering map WADs of which notability was not immediately obvious. The relevant cases were: OVERLOAD, F-DOOM, Vortex (all deleted), The NEW DOOM (kept), TheCraven, Bloodsport (still ongoing).

The unanimous (delete) votes about the unnotables were the easy ones, the devil was in the grey zone cases. The complicating factor usually was whether the WAD article was created by its author, and thus viewed as self promotion – intentional or accidental. The result of the OVERLOAD discussion was a pretty strict rule against that, only to be subsequently debated again w.r.t. Bloodsport.

Some editors argue to apply the rule, plain and simple; others that (undue) pressure resulted in the rule being instituted in the first place, or that it shouldn't automatically be applied but only when preventing abuse. I think that if a rule is controversial as currently written, then a way forward would be to refine it and build in some kind of leeway that makes it clear(er) how to apply it, in a way that's agreeable to more/most editors. Here a first stab at it:
"Such articles will most likely be deleted." expanded to:
"Such articles will likely be deleted, unless sufficient notability can be agreed upon."
This implies that grey zone cases always need to be discussed. As far as I'm aware, we are in general agreement about the nobility definitions. The first three were established in the first revision of the guidelines in 2010 and held up all this time, and the last one was added a bit over a year ago.

In recent years many editors have (ir)regularly contributed to covering a large number of notable WADs, and thus set a standard for which WADs are covered, and how well. That standard is, I feel, part of what makes our Doom Wiki the community wiki, and the overall state of the wiki has immensely improved in comparison to ten years ago. If a sub-par article appears about a notable WAD, the article can and will be improved sooner or later. But is that also worth our effort for any run-of-the-mill (or worse) WAD? There are only so many editors actively working on this type of article, and only so many hours in the day. Just look how long some articles have gone unreviewed and without cleanup.

Every article that's accepted about a mapset that's (way) below the bar, sets a precedent about accepting even more of them, and that just doesn't scale with hundreds of thousands of maps out there. Even if "real estate for articles is not limited" (dixit Quasar) or "a notable reception doesn't take much" (dixit Dynamo128), there is a limit to their associated images (server disk space, although not a practical problem for the foreseeable future since the storage expansion last year), and more significantly, to the human effort handling WADs and their maps. And specifically, the effort of this one human.

Before the age of XymphBot scripts (2016 AD), maps in WADs were covered very inconsistently, both in page structure/content/style and in which maps in a set even had pages. Only a few dozen WADs were on the wiki anyway. I spent hundreds of hours developing the scripts and bringing all existing WADs up to the same standard, and hundreds more on covering all the WADs added since. Every once in a while, a new contributor tries to create map page(s) manually, and doesn't even come close to the established standard. That's understandable, because it is a lot of work manually.

But it doesn't take zero work via the scripts either: .ini files need compiling and testing, maps need cropping (several editors assist with that...), custom thing lists compiled (...and with this), map views generated and properly scaled and double-checked, and finally a bunch of different scripts need to be run creating page skeletons with all general info, images, and specific details that we now expect under the standard. In summing this up I'm not looking for applause (already got the Espi, thank you again) but it does take plenty of time, like 15-30 minutes for a vanilla mapset or episode to several hours for complex megawads. I obviously do not have unlimited spare time for the wiki (neither do the editors performing those sub-tasks), there are other projects & sites I'm involved in, and several volunteer roles in the real world too. And I need downtime to recover as well.

So I (and we) need to make choices. The notability guidelines are one crucial way to choose, and thus, a notable reception "does take more than 'not much'". But how much more is open for debate. Another example are {{speedmapping series}}: covering such WADs is fine when sufficiently notable, but personally I (and other editors agree) normally draw a line at covering their maps. If a mapper didn't put significant effort into a level, why should editors put it into wiki coverage? There were exceptions (like the 32in24 series, covered when I still had capacity for that large series, and because they were considered very noteworthy), but generally we steer clear of map coverage. (Conversely, if mappers do put a lot of effort into their speedmaps, then perhaps they shouldn't be released under that moniker.)

In theory a wiki shouldn't be dependent on a single editor for a particular (but vital) process, but the reality is that for (multilevel) WAD coverage at the current standard, this wiki is. I'm not particularly happy about it myself, but don't see it changing soon because... it's complicated. Thus it's clear that we cannot simply accept any and all WAD articles, as it would burn me out (and that danger is never far away, TBH).

Lastly, it is easy for us experienced editors to quickly shoot down an inadequate article by a new contributor, or otherwise point out all that is wrong about an edit. I'm guilty of that myself too sometimes, and try to do better the next time. Several people have pointed out this atmosphere, viewing the wiki as a somewhat intimidating or even harsh place, and I don't think anybody wants a community wiki to be that. It's easy to get a little frustrated with sloppiness from people would didn't read the guidelines/FAQ, or who don't grasp wiki editing yet – but we all made baby steps in the beginning. It is harder to forgive when regular contributors continue produce edits for a year+ that still need a lot of clean-up, and don't learn from past feedback. Still, can we do more in making the wiki welcoming (again), like being more patient with newcomers, and perhaps devising better ways to help them contribute in meaningful ways? (Auto-)Post a welcome message with pointers to the talk page of new users, like some Wikipedia's do (e.g. my Dutch one)? Could be good intentions for the new year.

If you made it to the end, thank you for reading my thoughts. Please chime in with yours – at minimum with your take on the proposed self-promotion/notability rule change. And hopefully the above helps to resolve the two ongoing VfDs. --Xymph (talk) 11:07, 29 December 2024 (CST)

I'm in favor of the rule change proposal - the only question/concern I have is how sufficient notability is to be determined from here on out. I suppose DW thread likes/replies would be an easy metric to measure it by, but it also feels quite arbitrary to me if we start setting thresholds for those. After all, such metrics have been brought up in past deletion discussions, and it's not entirely unlikely that they'll keep being brought up in the future when those discussion inevitably happen again. I wish I had ideas of my own to present in regards to that, but either way, the question is up in the air. --MF38 (talk) 12:11, 29 December 2024 (CST)

Some of my comments/thoughts:

• First of all, the rule against self-promotion right now does not work. And in your formulation it loses its meaning completely. Because what's the point of such a restriction if, when discussing deletion, the notability criteria are checked regardless of who created the article? Let me remind everybody that at the very beginning I suggested self-promotion as one of the reasons for speedy deletion. Unfortunately, this did not go anywhere, and the later added wording about the prohibition of creating articles about your own content turned out to be useless, because it wasn't enforced by administrators.
• Secondly, it is obvious to me that the very first notability criterion also does not work and needs to be rewritten. It says "incredibly popular", but if we followed it exactly, a significant portion of the articles would be removed. Because, in my opinion, only mods like Brutal Doom or Eviternity can truly be considered incredibly popular. Many other mods, even those mentioned in Cacowards, can hardly be called popular. Because if 30-40 people played a megawad, this is very little for the Doom community, which includes tens of thousands of people around the world. Yes, there is definitely a problem with the metrics, it is very difficult to determine how popular a particular mod is. In any case, in my opinion, the popularity bar is set incredibly low right now, and based on the latest VfDs it will be lowered even further. In Wikipedia terms, I can be called a deletionist, and it seems to me that with the increasing popularity of creating mods for Doom, the bar for popularity should, on the contrary, rise.
• Thirdly, I think that the notability criteria for mods should be moved to a separate page, and not just be a small section in the FAQ. And I always found it strange that they are located on the FAQ page and not in the Policies and guidelines.
• And fourthly, a big problem is the relatively low activity of administrators right now, especially in terms of participation in deletion discussions. VfDs take months to resolve, and such pace is too slow even for our wiki. Quasar has been doing this almost single-handedly for a long time, and I am grateful for this, but his participation in discussions is too sporadic. Something definitely needs to change in this area.

Yes, I understand that we shouldn't turn into an enemy of the community and delete everything, but at the same time we (and they) shouldn't forget that we are an encyclopedia, not a catalog of all released mods, so a filter in the form of working notability criteria is necessary. And a filter will only be good if it is stable in what it lets through and what doesn't. --Nockson (talk) 13:23, 29 December 2024 (CST)

Honestly, as I go around cleaning up walkthroughs (and Xymph cleans up my clean-ups ;P), I've noticed a large number of articles w/o walkthroughs. So I think that should be considered: Is your map notable enough that someone will write walkthroughs for it within a reasonable amount of time? I also think that's a good idea for a project for 2025: how much can we shorten the map stubs category. I know that walkthroughs are much more involved than secret lists, (I've written a few myself) but I think it's something that has to get done at some point. --Robotcthulhu (talk) 04:52, 30 December 2024 (CST)

I made it to the end :) but unfortunately I've never found answers to your important infrastructure questions, so I can only talk about maps.

FWIW this might be the most users ever participating in a set of related notability threads. I hope that means there's enough momentum to hammer out a change — the lack of clarity has often been frustrating. (I wonder how many authors see prior deletions and decide not to even ask.)

Regarding "self-promotion", I believe that:

• Dynamo and Quasar have explained the original intent of the rule [1] [2]. Historically, 99.5% of authors have contributed in good faith. Admins only took notice when people posted effusive blog-like profiles and nothing else, or spam disguised as community content.
• Documenting history is extremely difficult, and doomwiki.org has struggled to convince the community that "anyone can edit" (IMO because every other project ends up with a gatekeeper). Therefore we don't have the luxury of turning our noses up at content just because the user happened to be involved. It may be our only route to an accurate stub, and there's always some chance the user stays to contribute elsewhere.
• New map pages are more visible than they once were. More review publications are active (?) and forum members seem to mobilize to help Xymph when a major WAD is released or receives an award. (Brilliant lateral thinking btw, not only helping the numerous readers who are suddenly playing those maps, but encouraging people with specialized knowledge to begin editing.) Also Quasar and others have worked for years to increase our Google rank and even market the site as the community's permanent archive when all others are gone. With such prominence, authors understandably want to stake out their URL of record.
• Xymph's "first stab" wording is an improvement, because the current version suggests summary decisions, which clearly have not been the norm (despite my own gloomy predictions when speedy deletion was introduced, thrilled to be wrong there!). I now see that the preceding entry already mentions deletion and consensus-building... in hindsight they could have been combined, and perhaps I only separated them because the existing writeups were already separate? Or I was just being sloppy, thinking that aspect would be read as carrying over implicitly.

For clarity, IMO any agreement on rules is best formed by the current regulars (as has always been the case, unless staff was forced to address an extrinsic situation). After all, they end up doing the heavy lifting afterward, including conversations with "newbies" who are actually not new to the Doom community, in many cases, and expect to be treated as peers.

Sorry to be the old fogey who shows up to make one post! I'm currently without various things including my passwords. KUTGW everyone.   MinimumJosei (talk) 14:00, 5 January 2025 (CST)

Bot message for new users

Xymph suggested this, but I think we should expand on it. Basically the idea is to have a bot that sends users a message after their first edit, like Wikipedia does. The message should go something like:

Dear (user's name),

Welcome to the Doom Wiki! To help you get started, we suggest looking at the guidelines and policies and FAQ to learn how to not get yelled at. Here is a list of things that are automated and that you should not do or it will get in the way:

(insert list here)

Thank you, and have fun,

(bot signature)

This is just a draft, please let me know if we should add or remove anything. Wording can be finalized later. --Robotcthulhu (talk) 19:18, 5 January 2025 (CST)

Well, I finally had some time/energy/inspiration to work on this, and while a few parts of the above are usable, the message should be both more neutral and more informative about common pitfalls. Based on NL wiki's English and Dutch welcome posts, I drafted the following:

---

Hello {{BASEPAGENAME}}, welcome to the Doom Wiki!

Thank you for participating in this community project. To help you get started, we suggest looking at the main help hub, where you can learn more about editing the wiki, understanding our guidelines and policies, and finding answers in the FAQ.

A couple of tips upfront:

• If you're just starting in wiki markup, then see these basic and advanced formatting explanations.
• To experiment, please use a sandbox.
• On talk pages, always sign your posts.
• Reply on a post to any talk page on that same page (not the poster's talk page), usually indented with one colon (:) more than the previous indentation to keep topics threaded.
• Put a meaningful explanation of an edit in the Summary field, and Preview edits before Saving them to review and resolve possible mistakes before they are stored.
• Some (repetitive) activities on this wiki are automated via XymphBot scripts, and could be tiresome to perform completely and consistently by hand. You can submit requests to Xymph or ask on #doomwiki.
  Specifically, creating articles for all maps in a multi-level WAD with navigation box, secret sectors, statistics, map image and other standard information is better not attempted manually, as such efforts are much more cumbersome to perform than – and would get in the way of – the scripted passes.
• Check back after a day or two to see how your edit(s) were reviewed, and learn from any changes that may have been made.
• Looking for something to do? Check the "DoomWiki.org needs you" section on the homepage.

Thank you, and have fun,
--WelcomeBot – date('H:i, j F Y (T)')

---

What do you folks think? I still need to write the welcomeBot script (which will execute the date command at posting time). --Xymph (talk) 16:33, 20 February 2025 (CST)

That's just… WOW. Everything I was thinking of, but phrased better than I could have. This looks perfect to me. One idea, though. Maybe wait ~8 or so hours after their first edit, in case it gets undone or deleted because of spam, so the bot is not creating a talk page for a spambot account that gets deleted/blocked. Also, add a segment on how they can help out with certain things, like:

---

If you want to help out, you could:

Write walkthroughs for maps that need them.

Add music tracks to WADs that need them.

---

That's it. Looks great! --Robotcthulhu (talk) 20:18, 20 February 2025 (CST)

Thanks. I don't think a general welcome message should steer people into two specific areas; what they can and want to do here depends primarily on their own interests. I added a pointer to the general list.

As with all my scripts, welcomeBot will be a script running on a bot account, not an autonomous bot. I haven't thought out the details yet, but probably the posting script will just post the message by my manual action, while a separate script will find recently created accounts with at least one edit, for consideration to post the welcome to. Further automation to be less dependent on me can be considered later. --Xymph (talk) 04:35, 21 February 2025 (CST)

Sounds great! --Robotcthulhu (talk) 08:54, 21 February 2025 (CST)

Sounds good to me. --Dynamo128 (talk) 10:30, 21 February 2025 (CST)

Supporting Gez's suggestion further on, because boy that is useful. Additionally, perhaps one could link to a few active editors who are willing to answer any newbie questions? Let the Bot do the work for us for the most part, but leave always open that new users can talk to other users. --Redneckerz (talk) 14:52, 21 February 2025 (CST)

Talking to users or asking in Central Processing is already mentioned in the help center & guidelines, so I think it's better not to increase the message length even more. --Xymph (talk) 11:03, 23 February 2025 (CST)

I'd suggest this tweak:

---

* To experiment, please use a [[Doom Wiki:FAQ#Where can I experiment with or draft a page? Is there a sandbox?|sandbox]], for example [[{{FULLPAGENAMEE}}/Sandbox|here]].

---

--Gez (talk) 13:15, 21 February 2025 (CST)

Done, but with Special:Mypage like in the guideline. I've created the {{Welcome}} message as a template, so it is easy to modify if needed. I've also written welcomeBot.php (as a single script). It can post the template plus signature to a user's talk page if that is empty. If it already exists, the window of opportunity to post a welcome has typically expired, unless someone feels it can still be appropriate?

The script can also go over the past XX days of the new users log, select users with at least one edit and an empty talk page, and post the message to each. XX is currently 90, allowing to catch up on relatively recent accounts. After a catch-up sweep I will lower the threshold and (ir)regularly run the script a few times per week or so. Would that work for everyone, including the 90-day window (from 25 November 2024 onwards)?

What I didn't realize until adding the template is that a {{WelcomeAnonymous}} template already exists since 2015 – but it has never been posted anywhere. It uses different wordings in a few places; should that be adopted in the new message for user accounts, or some middle ground be used in both? --Xymph (talk) 11:03, 23 February 2025 (CST)

All of it looks great. I don't think that the window of opportunity has passed for a welcome message just because someone has posted to a talk page, but also the number of situations where someone would need to post to a new user's talk page to warn them about something, (without them being a spambot or troll) is significantly less than that of the number of new users that just make one or two edits that can be gently corrected in the summary of your cleanup. I didn't get my first talk page message for a little while, at least. In those situations, because of the rarity, it would probably be easier to have the script flag them for you to copy and paste the message into. The 90 days for the first pass sounds good. Quasar is pretty good at blocking the aforementioned spambots and trolls, so after that, if you are doing it intermittently, it should be fine. --Robotcthulhu (talk) 19:51, 23 February 2025 (CST)

I noticed some accounts were created months before their first contribution, so I extended the script to show the account creation date and the dates/paths of their first ten edits, and started the new account scan around 500 days ago, but ultimately selected only accounts created since around Oct 1, 2024 (about 150 days ago), unless their only edit(s) were to their user style sheet (which seemed to be a bit of a rage last Fall) or they had already made so many edits to make a welcome no longer meaningful. In the end, 57 accounts received the message. And that's a wrap for this project. Thanks to those participating. --Xymph (talk) 07:52, 24 February 2025 (CST)

Map stubs category keeps growing

Hey everyone, I noticed that we are adding map articles faster than people are writing walkthroughs for them. I think a good goal for 2025 would be to write a lot of walkthroughs to whittle down the size of the Category:Map stubs category. Anyone else have anything to say on this? Edit: As of this edit, there are over 16,000 map stubs in that category. --Robotcthulhu (talk) 07:09, 8 January 2025 (CST)

While I see why the number of articles in the map stubs category is of concern to you (and possibly some others), I don't feel that starting to write walkthroughs for 16,000 maps is entirely realistic. What are the odds of its size having been reduced by even 1,000 by the end of the year? Writing walkthroughs and secret descriptions is its own kind of skill set (props to Gauss and Getsu Fune for their efforts on each of those respectively), and doing that for a 5-digit number of map articles especially is a task that's virtually impossible with our current manpower. I think what would be a much more attainable goal for the time being is de-stubbing articles that can be deemed worthy of the treatment in their current state and then start thinking about what sorts of steps need to be taken to keep that situation from getting out of control. Which, let's be real, it already is. --MF38 (talk) 11:35, 8 January 2025 (CST)

I don't see why the size of this maintenance tracking category is a problem as such. Wikipedia has tracking categories with tens of thousands of entries too. The different speeds are inherent to automation of page addition vs. the time-consuming nature of playing and writing up walkthroughs. You can inspire other editors (lead by example) to work on lowering the count, but not prescribe them what to work on (unless I'm reading too much in "that has to get done"). If you scan back over the past few years of wiki summaries, it becomes apparent there is only one editor (indeed, Gauss) systematically addressing this area. So be it. At any rate, bot-wise removing a stub template for pages that are lacking Essential content (capitalized for its namesake section) is the wrong way to deal with maintenance tracking, and also pointlessly racks up the wiki's edit count by 16K. Personally I think it's fine to leave map stubs alone, and any editors interested in improving the wiki could more effectively focus on the Cleanup and Stubs categories, and some of the orphaned pages. (Also, capitalizing every word in a sentence is poor English. ;-) ) --Xymph (talk) 06:44, 9 January 2025 (CST)

I think MF38's idea is good, because of simple math. If we add 45 map articles a month (just an arbitrary number), and we write 30 walkthroughs, the map stubs category will grow. But, if we write 46 walkthroughs, then it starts going down. I also figured out a trick: If you use a map editor to look at linedef types and thing placements, you don't have to do all of the dying and playthrough. You lose some of the things like what strategies are effective (except for where it's obvious), but it's much faster (and thus more efficient) than playing through the level. --Robotcthulhu (talk) 09:24, 9 January 2025 (CST)

Just to interject, submitting walkthroughs without playtesting is a recipe for trouble, even if you're like me and you don't include tactics and strategies. There have been times where I've written a long walkthrough, then had to go back and rewrite entire paragraphs because I missed an important detail. Hubs and maps that use scripts are even more error-prone.

On topic, short of banning the creation of any new pages, I don't think we will ever get the number of stubs down to a manageable number, nor should we be overly worried about it. As noted above, Wikipedia has thousands upon thousands of articles that will never expand beyond stub level, nor does it set any deadline to fix them. If we could get more people involved in wiki work - and get them to stick around - then I think that would be better for the project in the long term. Gauss (talk) 09:54, 9 January 2025 (CST)

Code syntax highlighting

Is there a way to do syntax highlighting for code blocks in articles? This is standard for viewing code pretty much everywhere, and for good reason; without syntax highlighting, it is difficult to read the overall structure. It makes sense that a wiki so closely tied with a game engine should have good support for discussing the code in the engine, and what we are currently doing is discussing a lot of code but with little support for it.

If it is not possible to do currently, is it reasonable to ask for it to become possible? Additionally, it would be fantastic if languages other than C can be supported (ZScript, ACS, DeHackEd, DECORATE and more). -Inuk (talk) 12:36, 16 February 2025 (CST)

This should be possible with the SyntaxHighlight extension, which is currently not installed but (surprisingly) should work with our ancient MW version 1.27. Supports hundreds of languages, but not our niche scripting languages – though it may be possible to develop that if someone invests the effort. Installing the extension would be an admin task. --Xymph (talk) 15:02, 16 February 2025 (CST)

Sounds within reach. Since it is now on the table and I regularly see articles with code, I will hold you to it to talk with an admin about installing it. If need be, I will pester any admins I come across myself.

Reading about SyntaxHighlight, it sounds possible to create custom lexers for additional languages, but it would probably require more admin action to enable each for Doom Wiki. One thing at a time. -Inuk (talk) 17:23, 16 February 2025 (CST)

We previously had SyntaxHighlight GeShi and after taking the effort to put it in to multiple articles, that extension was discontinued and then replaced with one which requires Python as a dependency on the server. I don't want to add the overhead and the security hazards of an out-of-date version of Python to the otherwise completely pure php codebase of the current MediaWiki install and have that be yet another thing I have to maintain the functionality of in perpetuity. If somebody wants to come up with a better option that's written in php then I'd consider it. --Quasar (talk) 22:04, 17 February 2025 (CST)

What's wrong with the GeSHi? Being discontinued isn't inherently a bad thing, and using it sounds like your ideal scenario. -Inuk (talk) 06:39, 18 February 2025 (CST)

I've been installing and running GeSHi locally to see what it can do, it is indeed very nice that there are no extra dependencies. Support per language is defined in its "geshi" folder as a .php file, and you can make custom language support pretty easily by copying an existing .php file and editing it. GeSHi collects all the language definitions from the directory, no extra config required. ACS syntax highlighting already exists for Ultimate Doom Builder; go to its GitHub and navigate the Build/Scripting/ directories, I can translate it to GeSHi easily if needed. Seems perfect to me. -Inuk (talk) 03:51, 19 February 2025 (CST)

The extension to adapt it into MediaWiki is out of date by multiple versions (I think it was discontinued as of 1.21 or so); it would be necessary to fork it and maintain it by bringing (and then keeping) it up-to-date against MW. I already do that for several extensions plus the custom skin, though it's been entirely too long at this point since we last updated - partially because of that update overhead. --Quasar (talk) 09:52, 19 February 2025 (CST)

If you don't feel like maintaining it for perpetuity then I'll do it, better than maintaining the mediocrity of code articles for perpetuity. Got things going on and I'm not familiar with MW so it'll be slow going... pointers for a starting point and what this usually entails? -Inuk (talk) 13:12, 19 February 2025 (CST)

Styling of key actions in articles

I have noticed that throughout the wiki key actions are styled in different ways. Some write them just as is ("Press use to lower the elevator."), some use capitalization ("Press Use to lower the elevator."), and others wrap them in quotes ("Press "use" to lower the elevator."). I have also seen a few that put them in all uppercase ("Press USE to lower the elevator."). Perhaps we can agree on one styling method going forward.

I personally think capitalization is the way to go. Key actions are generally presented in capitalized form in menus and this clearly differentiates them from their regular counterparts ("You can use the switch by pressing Use."). Quotes, in comparison, can introduce potential ambiguity, as they are normally used for special emphasis. Any thoughts? --Gregor (talk) 14:28, 27 March 2025 (CDT)

Capitalization makes the most sense to me, so I'm in favor of that. No further comments from me. --MF38 (talk) 15:51, 27 March 2025 (CDT)

There was a special template created for showing keyboard keys last October - Template:Kbd. Of course it is not that suitable for "Use" and other such stuff, but for one button commands it is pretty good. And yes, I also in favor of capitalization. --Nockson (talk) 16:13, 27 March 2025 (CDT)

I, personally, use quotes. Since pressing "use" is not something done in-game (vs. opening a door or killing an enemy), I think it should be separated completely. Also, in all of my walkthrough fixing/cleaning up, I have never come across a walkthrough that used quotes (barring one or two). In this case, the quotes are to show the reader that the action is separate from in-game actions, not to emphasize that they need to press use. And, yes, I think the standard, no matter what, should be "press 'Use'" (or whatever), not just "Use". That's my rant. Sorry. Get carried away. --Robotcthulhu (talk) 19:57, 27 March 2025 (CDT)

From my POV, the name of a key or of a bindable action is not a proper noun, therefore it should not be capitalized like this when occurring in prose. The use of quotes to indicate that it is a literal action name is appropriate grammatically speaking. --Quasar (talk) 10:11, 28 March 2025 (CDT)

I'm not arguing that quotes in this context are grammatically incorrect. I'm saying they are potentially ambiguous to the reader, since they are normally used for other things on the wiki such as words as words ("The word 'use' appears often in walkthroughs.") and the title of songs. With regards to whether or not key actions qualify as proper nouns: In my opinion, when I write, "press Use to lower the elevator", I'm referring to a proper noun since "use" does not denote a class of nouns ("Press the switch to lower the elevator.") but a unique in-game action that is bound to a specific key by the user. "Press Use to lower the elevator", prompts the reader to press whichever key they set to trigger the action of Use to be performed in-game. That makes it a proper noun in my eyes, and the word should therefore be capitalized.

But I think we all agree that key actions should be highlighted in some way to set them apart from generic verbs. One potential way of highlighting I forgot to mention above is using bold ("Press use to lower the elevator.") but I don't think that is an option for this wiki anyhow since bold is already reserved for specific purposes in an article (such as sector, thing, and linedef numbers). The choice is then between capitalization and double quotes, and this really comes down to whichever style guide you're subscribing to. But since we are operating in the context of video games, I think it is worth pointing out that it is (was) common for game manuals specifically to make use of capitalization to highlight key actions. The Doom manual also does that for keyboard keys: from the Doom manual, "To open most doors and operate switches, stand directly in front of them and press the Spacebar." Quotes on the other hand are rather unusual in this context, so that's another argument in favor of using capitalization.

Of course we could also just stick with every editor using whatever they like as long as it is used consistently within an article, but that's why I raised the question to see if we can agree on one option going forward. --Gregor (talk) 18:22, 2 April 2025 (CDT)

"Pacifist Paradise" page

Not that this is really something I'm planning to tackle really at any point but if anyone else is like generally familiar with Pacifist Paradise, what would you all think of a page for Pacifist Paradise? I feel like what I have in mind is kind of unprecedented as I guess the closest comparison to this page would be the PUSS page, like in my head how I'd imagine this Pacifist Paradise page is it'd feature a general overview on the types of maps that come from there, maybe list notable (subjective I know) mappers and list wads from Pacifist Paradise and closely related wads such as 1x1 or Poogers for example, like it'd sort of be like those pages for clans I guess, I dunno maybe this is a bad idea, figured I'd just shoot it here though --NiGHTS108 (talk) 19:17, 11 April 2025 (CDT)

Mappers with map pages without pages for themselves

Would it be possible for some kind of easier way to get a list of mappers that have a map page but no page for themselves? Like a category for that specifically or redlinking mappers with that property? They do seem to meet the notability criteria based on the previous couple pages I've made going smoothly, so it'd be nice if there was an easier way for me to quickly pick these out, especially since mappers seem to be redlinked kind of rarely. Thanks! --NiGHTS108 (talk) 18:44, 14 April 2025 (CDT)

The rule of thumb is to create a mapper article when at least two maps in distinct projects were notable enough to be covered, and that mapper has made at least several other releases/contributions, or has other notable accomplishments (like a sizable number of demos, a Cacowards newcomer mention, or video content creation). This has been discussed several times in the past, but is not a hard guideline. Most of the mapper articles you created meet the above, only Scionox and cassis have just one covered map – but their BoW's were sizable enough otherwise that those are fine too. For mappers with only one covered map and little else, that would be premature though. And Fumingbow639067 has no covered map yet, hence I haven't moved that to main space yet. --Xymph (talk) 04:06, 15 April 2025 (CDT)

I see. Understandable in that case, thanks! --NiGHTS108 (talk) 09:12, 15 April 2025 (CDT)

Credits map notation within WAD pages

Just wondering if we can reach a consensus on how to note maps that are credits maps/epilogue maps/etc. I noted the credits maps on the Junkfood pages with the format of "MAPXX: Name (credits map) by Author", but these were all changed to "MAPXX: Name by Author (credits map)"; I put the credits map notation after the map name because all the WAD pages I've seen that note things like "(exit to secret map)" do so directly after the map name and not the author's name. IMO this is the more sensible way of displaying this info, but I'd like to know if there's already a precedent for this sort of thing, or if one can be decided on if not. Thanks! --Grapes (talk) 00:09, 29 April 2025 (CDT)

Good that we can discuss it. I remember mostly the opposite examples, like Eviternity II page, that's why I changed the format. I think my way is a little better because the notation doesn't blend with the level's name, especially when there are no wikilink. The only thing I'd also add is the usage of italics. --Nockson (talk) 01:04, 29 April 2025 (CDT)

Yeah it looks like it's a bit inconsistent for any sort of map notation, even secrets, which is another reason I wanted to discuss it here. I leaned more towards putting the notation in the middle because it feels more like "Map number 32, Evil Is Over, a credits map by John Mapper" when I read it that way. But, I definitely prefer how it looks on the Evit2 page with the italics; I would be all for putting every notation after the author if they're all consistently italicised like this. --Grapes (talk) 09:27, 29 April 2025 (CDT)

Regarding the position of the in-brackets label, I don't understand the confusion to be honest. The label should be placed after the map name and author (if listed), just like the "secret exit" labels, and obviously use italics. This same format is used in articles for the commercial games, and across the wiki. What kind of examples are you referring to where this is done differently?

Now, I missed the creation of credits map page a few weeks ago but I'm not quite sure if that was needed to be honest. We already have a Credits maps category. The new credits map article consists of no more than a short definition and a few examples. But the definition could also be placed at the top of the category page where the maps are listed below anyways. I did a similar thing for the Icon of Sin levels. Also, if we gonna have an article about outro maps, it should cover all types; the term "credits map" is too narrow in its application. After all, not every outro map is a credits map. For example, the outro maps in Jumpwad do not feature any credits. Or take the outro maps for Overboard. MAP30: In the End of Sign of Torment is a full level but without any enemies, just to get the player into a specific mood as a sendoff. Another example of that would be MAP05: Me Despido of El Viaje de Diciembre. Or take MAP30: The End of Ancient Aliens, which is both a "thank you for playing" and story map, but not a credits map. That's why I personally use the term "outro map" in my articles; it covers all cases, including credits maps. In the case of MAP37: Credits of Eviternity II, "credits map" is actually a bit of a misnomer since that map contains enemies (albeit secret ones) that when killed end the map. So it's not really a proper credits map. MAP22: Twilight of Neo Shotkon City from DBP37: AUGER;ZENITH is a better example, but again, there is an exit switch in that one as well, so it's not a dead end. An example of a proper credits map would be MAP17: Epilogue Tour from Micro Slaughter Community Project or MAP22 from 1x1, but those don't have articles. Which is another point: a straight forward credits map is unlikely to get an article because there is no gameplay in it, so when an outro map does get covered, it properly is more than just straight forward credits map, in which case the "Credits map" label is actually misleading because it implies that the map contains no gameplay, potentially discouraging players from fully exploring it. So I think such labels should only be placed in map listing when the map really does not contain any gameplay and the label makes sense to avoid confusion—for instance if the credits map is placed in an unusual spot in the map progression (not final map). If the map does not have an article, that already indicates that it's an outro map without gameplay. This can be further clarified by mentioning it in the intro paragraph. I did this is in the Jumpwad article for example. --Gregor (talk) 13:53, 29 April 2025 (CDT)

Actually, the article was created first followed by the category in a few hours. I don't think that category description is a valid replacement for an article, even this short. Categories is not something you would normally link in a text. I don't think outro map is a valid term, for example is MAP30 of Doom 2 an outro map? And do we need an article about intro map then? Credits map is a pretty much widely accepted term, a lot of DBPs for example use it and label it as such. And, as written in the article, credits map can or cannot have gameplay, the main factor is having a list of credits in some form. --Nockson (talk) 14:30, 29 April 2025 (CDT)

I don't understand the Doom II MAP30 example. Of course that's not an outro map, neither is it a credits map. It's a boss level, but otherwise a normal map. Outro map implies an epilogue of sorts after the main finale of the map progression. MAP30 of Doom II IS the finale so it obviously does not qualify. And as we all know, there is no outro map afterwards. It might be helpful to remember that originally these types of maps were placed in projects to stop the player from entering a default Doom II level after the last map of the set (before UMAPINFO solved that issue). MAP24 from BTSX Ep.1 is a good example. And like I pointed out with my examples above, there are plenty of these types of maps placed at the end of map sets that do not contain any credits. They are often just used as a mood setter or story-telling device. Displaying credits in them is just one of many possible uses.

I'm not saying there should not be an article for that, just that it should cover the full scope of these types of maps, instead of focusing on one variant of it. What would you call MAP24 of BTSX or MAP08 of Jumpwad? They're definitely not credits map. But they serve the same basic purpose as a credits map. That purpose is not to display credits but to function as an outro after the finale, independent of whether credits are displayed or not. And btw, the DBP mappers using the term credits map for actual credits maps makes perfect sense, but that does not mean it should be used for other types of outro maps as well. I've seen the term "Thank you for playing" map being used quite often as well. But that again describes a specific type of outro map. So an umbrella term is needed, and I think "outro map" is fitting because it describes the basic function that all of these types of maps have in common while being general enough to allow for different variants without creating confusion—unlike the term "credits map" which very specifically implies a map were credits are displayed. I guess you could use "epilogue map" instead, but "outro" is more concise, neutral and straight forward, while "epilogue" implies to me a more story-driven experience like MAP30 of Ancient Aliens or MAP14 of Overboard. --Gregor (talk) 16:10, 29 April 2025 (CDT)

Ah, now I understand, I knew this type of maps as progress-stopping. I thought you meant any final map, sorry. Well, maybe renaming/expanding the article is the way to go. But the important thing is the name - what is the most widely used name for this type of maps? Before creating the article I checked that "credits map" is used a lot. Can you do the same for outro/epilogue map? --Nockson (talk) 01:06, 30 April 2025 (CDT)

I was considering bringing up epilogue/outro maps on top of the placement of notation so I'm glad the discussion snowballed into it naturally! I do think we should ideally collate credits/outro/epilogue stuff into a single page if possible. I'm in the camp of just keeping the page as "credits map" due to its frequency of use on and off the wiki, but I would say "outro map" or "concluding map" would be a good collective title ("epilogue" should probably be saved for when the WAD specifically uses this language IMO). It would be cool to have all of these variants on one page with a brief summary of what separates them, expanding on the current description with regard to terminating before IWAD levels, whether gameplay/exits exist and why, etc. In regards to expanding the page I was planning on adding a section about the history of how they've changed over time (i.e. #1DWANGO utilising a SKY texture versus the scale of stuff like POOGERS MAP36). --Grapes (talk) 01:54, 30 April 2025 (CDT)

RE: Nockson → I'm not sure if the popularity criterion should apply when the term itself does not make sense in the context it is used or does not describe the content accurately. If the decision would be between "outro map" and "epilogue map", and "epilogue map" would be more widely accepted, I could understand your argument, because both terms imply the same thing more or less. But with "credits map" we're implying a very specific type of outro/epilogue map used specifically to display credits. It is very clearly a subordinate term, so using it as a hypernym for the category of maps it belongs to is a logical contradiction in my opinion. It only makes sense for that one specific type of outro map, whereas the other two terms can be applied to all different types, including the ones that do in fact contain credits. I think a name for a category of maps needs to first make sense for the content described, then we can argue about accepted use. --Gregor (talk) 16:21, 4 May 2025 (CDT)

Anti-consumer practices

I think we could go further in documenting and organizing presentation of anti-consumer practices. We touch on these with categories for Downloadable content (which is not always A/C but can be) and de-listing. However there are others, all of which have examples in the Doom series already thanks to our increasingly insatiable overlords:

• FOMO
  • Time-limited content
  • Limited-edition items
  • Pre-order bonuses
    • "Early access" (Artificially delayed access for most consumers)
• In-game purchases
• Premium cosmetics
• Pressured engagement / Login bonuses
• Games-as-a-service approach / Login required / Always-online components
• DRM encumberment
• Third-party account or purchase requirements
• Games of chance / Gambling

Creation of categories would be a minimum but I think these things should also have fairly high visibility on the affected titles, so that people can be informed about their presence before making a potential purchase decision. Especially the ones that engage in predatory psychology. --Quasar (talk) 18:20, 30 April 2025 (CDT)

Amazing idea. Yay, capitalism :P. I think that touching on this in upcoming games' articles is a good idea, and having either:

1. A page for each of the above, describing what it is and how it works, and what doom games have done it;
2. or a page for each of the games talking about specific things that game did.

Anything else? --Robotcthulhu (talk) 19:29, 30 April 2025 (CDT)

Doom TDA weapon splits

So there are weapon "classes" in Doom: TDA and each class seems to have two weapons in it. Due to pre-release confusion (the names changing a few times in some cases, or being extremely unclear as to which was being referred to and what the difference even was—were they just mods of each other or not??—we pretty much have one article per class right now instead of one article per weapon. I'll bring this up here for consensus but I think that, to be consistent with every other game, we'll want one article per weapon and not per class, though, perhaps there should be an article on weapon classes; or else it can simply bear mention in each individual article and in the master weapon article once that gets updated. Input is welcome before I go nuts with splits. --Quasar (talk) 14:01, 11 May 2025 (CDT)

The only review I've seen that really talks about this is from IGN (bleh), who state: "every gun has a sister weapon that uses the same ammo type and can be hotswapped between with the press of a button". So I imagine that we will end up having one article per weapon rather than per class. Gauss (talk) 14:52, 11 May 2025 (CDT)

Yeah. My thought is to do something similar to the Doom 3 weapons template once we know what keys are assigned, since the weapons of each class are apparently assigned to the same key. --Quasar (talk) 15:20, 11 May 2025 (CDT)

Adding in-universe timeline?

I'm quite new to Doom, and I'm confused as to why there isn't a page highlighting the in-universe chronology of the current DOOM canon? —The preceding unsigned comment was added by Fiblin91 (talk • contribs) .

I'm new to the wiki in general but Doom does not have a canon document that has been released by id. At best, we have various interviews by Hugo Martin(even he has admitted to not knowing how Doom 3 fits off the top of his head) and some tweets or posts by different original id devs clarifying some things. By my reckoning, the best we could do on that front would be divisive to some concerning expansions like Sigil and The Legacy of Rust. If such a page is created, I think it would need to be classified as unofficial at best. --Deman102712 (talk) 11:58, 15 September 2025 (CDT)

Rollout of template editing protection level

We have added a new article protection level for templates. Editors, reviewers, sysops, bureaucrats, and bots have this permission implicitly so if you are any of those you will see no difference. Otherwise, I have applied the new protection level initially to all templates which are either an apparent part of the interface, part of the official policy pages of the wiki, directly generate invisible HTML components or metadata, are extremely complex in implementation, or have more than 250 total transclusions.

I will accept requests for any other templates to be added. I will also be adding the protection to any template which gets vandalized going forward, with zero tolerance. Templates are too powerful and too potentially damaging to the site (up to crashing the server if edited repeatedly or affecting thousands of pages at once) to allow fully open access to them any more and this has been the case for far too long. --Quasar (talk) 15:11, 29 May 2025 (CDT)

Great work! Can you please also apply protection to Template:Dpforums and Template:Kbd? Thanks in advance! --Nockson (talk) 15:24, 29 May 2025 (CDT)

Done. --Quasar (talk) 17:36, 29 May 2025 (CDT)

FWIW this seems like a completely reasonable change in context.

MediaWiki:Protectedpagetext says: "you can submit an edit request by clicking the button below and following the instructions." Am I the only one who can't see a button? All the best. MinimumJosei (talk) 08:01, 13 September 2025 (CDT)

That was accidentally copied unchanged from Wikipedia which did have a button there, but I am unsure what that button did and if it can be copied here, since their templates have functionality ours do not (chiefly, Lua-based server-side scripting). I'd have to track down where I got it from originally. --Quasar (talk) 11:14, 13 September 2025 (CDT)

When it's ok to quote social media as a source

We might need to tighten up our policy game here. It's becoming increasingly common for users to spam their favorite influencers or content creators' videos as a source for simple facts that are self-evident in the games themselves. The reason such links were ever appropriate was because of officially sanctioned pre-release info derived from Bethesda itself originally but only available through such sources. So for example it was entirely appropriate to quote, say, GManLives, when he showed off info about TDA before launch. It is not fine to quote RandomDude3932809's "Doom TDA monsters" video just to state that imps throw fireballs. This is not an encyclopedic source. I think we have a lot of cleanup of these junk references to do at this point and I fear it'll be difficult to find them all. --Quasar (talk) 08:57, 11 August 2025 (CDT)

This may apply for truly random clips/tweets, but not for the one removal that prompted this topic. For glory kills in Doom 2016 and Eternal we have sourced all such listings to a select few videos (that project isn't actually finished, it seems). The complete set of glory/execution kills per monster does not seem self-evident to me (not having played any modern game to a significant degree), and is hard to produce in-game yourself. Moreover, the lists were contributed by Wad Overdose (= 217.196.161.220/217.196.163.185/217.196.163.217), whose (I'm sorry to say) neverending sloppy editing is impossible to review without reference videos that show exactly how correct the wording about each specific kill. And I burned out from that this Summer so haven't even touched the TDA additions. The clips used for 2016/Eternal therefore should stay, and the TDA clip returned, because they are not random gameplay videos but complete collections of animations we want to document completely. --Xymph (talk) 10:44, 11 August 2025 (CDT)

One-sentence person articles

Here is a list of person articles that contain one (rarely two) sentences. These persons have only one contribution each, be it a source port or a program, or even just being a community steward. In my opinion all these articles should be deleted, since just one contribution (no matter how important it is) is not enough to warrant an article. It seems to me that the common practice of having at least two maps with pages in different projects for an article about a mapper should be applied here as well. Simple wiki logic - if it is impossible to write more than one sentence about something, then there is no need to write about it. --Nockson (talk) 14:48, 29 August 2025 (CDT)

The list:

• Florian Schulze (Proff)
• Jeff Rabenhorst
• Brad Harding (also created by the person themselves)
• Firebrand
• Hannu Viitala
• Dean Wiley
• SuperGod
• Paul Winkler (Hughe)

"since just one contribution (no matter how important it is) is not enough to warrant an article" has never been a rule, nor even a suggestion of a rule. The notability of a contribution is absolutely a factor as to whether someone can be covered. The very first example is the author of PrBoom, one of the most important source ports that will ever exist (still serves as a go-to for "ports" to various Linux devices). He was never a very public persona so it's understandable that people don't know much else to say about him. --Quasar (talk) 10:03, 31 August 2025 (CDT)

I agree with Quasar, these people should absolutely stay in my opinion. --Dynamo128 (talk) 10:10, 31 August 2025 (CDT)

This information (about Proff) already exists on the PrBoom page. What's the point of a separate article if there's nothing else to add except that? I am not saying that they are not notable, I am saying that the article about them has no purpose, because all that info is present elsewhere. --Nockson (talk) 10:16, 31 August 2025 (CDT)

I concur that most if not all these articles should stay. All except perhaps Hughe are indeed notable enough from what I can tell (e.g. Rabenhorst is thanked in 70+ idgames files, so widely known in the Doom community of that era). When an article is exists, there remains a chance – however slim in most cases – that an editor or passer-by can easily contribute some relevant tidbit as yet. If the person name redirects to another article (a port or whatever) then that is hampered at least, or the contributor just won't bother at all as more personal info doesn't actually belong in such a context. A person redirect to a non-person article feels a little awkward to me, although I don't know whether there's precedent for that.

The second reason for keeping is that most articles have been around since before the fork, and thus any search engine queries for their names produce at least two results: the non-community, commercial wiki and us (usually in that order, alas...). If we change them into redirects, our search result ranking for those queries will tank drastically, or disappear. That's rather undesirable for queries for community members. In other words, I see Nockson's point that, if they didn't exist yet, we wouldn't have created some of these articles for a lack of material to write about and fairly little notability (e.g. Viitala or Wiley), but since they've existed for ages it would be unwise to prune them now.

The only article I'd question is Hughe, as I don't know if creation of plushies (which aren't available to the community, contrary to Hissy) makes him that notable, and all the same info is indeed in the Pixel section. But with the argument of article age I could also understand when others insist on keeping it, for that or perhaps another reason I haven't thought of. --Xymph (talk) 15:24, 26 October 2025 (CDT)

I don't question the notability of most of these people, I'm questioning the point of existence of the articles. Example: person A created the program B and no other info is known about them. A reader comes to the wiki and reads a large, thorough article about program B. They then click on a wikilink to the article about person A, hoping to get more info. And what did they get? "Person A created the program B." What's the point? If person A also made a level C, it would make sense, a new info, another article to read. But in its current form it has no useful purpose. It just an unnecessary loop, all of this info is already present in the article about the program B.

But if this is the case then why are you stopping Walter from creating articles about TNT mappers who only made 2 maps? IMO these pages would make much more sense as a way to interconnect their contributions. Nockson (talk) 01:05, 27 October 2025 (CDT)

Didn't say you were doubting notability, and I already addressed the points of the articles' existence that I can think of. Others who responded above in favor of keeping them may have other reason(s) in mind. Your view about this creating loops makes sense if you only consider the wiki as a self-contained bubble, but I think we also need to keep in perspective that it's (a central) part of a big community ecosystem, and the Internet at large. Hence my arguments above.

Mappers' covered maps are already connected (admittedly somewhat obscured) via their mapper categories, and there are thousands of mappers who released only one or several levels. IMHO that's simply less notable than (co-)developing an entire source port, so we put up a higher bar for covering new mappers. I also wouldn't be in favor of covering the (many) redlinked contributors to EDGE unless we can write up more than 1-2 sentences about them. But once an article exists about someone notable, it doesn't make sense anymore to delete it after a decade+. --Xymph (talk) 06:53, 27 October 2025 (CDT)

Multiple questions

Greetings! I hope you guys can help me out with some questions I have.

1) Is there a way to bulk upload images? I have ~150 screenshots ready for the Doom 64 pages, one per level. They're all consistent in dimension/format/name and are optimized for filespace. Total should be a little under 60mb.

2) Are there alternate methods to source trivia/I&D? I know tons of fun info on Doom 64 wads/levels but have no way to source it. Most communication in the Doom 64 community is done on the discord, which I cannot link to.

3) If I'm the author of a map/project, can I add trivia/I&D myself and have it considered properly sourced? Or is an external source still required?

4) The Doom 64 megawad Beta 64 has an author-approved remaster by Styd051. How would I go about adding that to the Beta 64 page? It adds a new level halfway through which changes the map order, can I add that in it's own seperate section so it won't affect the currently listed map order?

5) On userpages, is it worth always adding external links to the respective doomworld profile and youtube/twitch channel (if focused on doom content)? Immorpher's page for example links his youtube ,twitch, twitter and bandcamp page.

6) Is this individual notable enough to warrant having an article made for? I believe it is the case based on existing standards.

Jetx_121 (doomworld.com/profile/27466-jetx_121)

- Made his own 12-map wad Lunar Revelations.
- Contributed to several community projects (Ethereal Breakdown, and the soon to be released Vehemence). 
- Contributed multiple pieces of music to several projects (Ethereal Breakdown, The Unmaking, Doom 64 Reloaded). 
- Is a prominent member of the Doom 64 community.

Thank you. Zoyahu (talk) 07:29, 12 September 2025 (CDT)

Whoa, a thread about citations. :D

For #1, no. I'm pretty sure it can be done by writing your own javascript, but if you want to do that, please ask the staff first as bandwidth issues have occurred in the past.

For #2, we have never required sources for technical content, such as the structure of a map or what the readme says about tools used, because it's assumed any skeptical reader could check it using widely available files. This has extended even to specialist knowledge (node building math, lanparty setups, re-compiling a ZDoom beta from 20 years ago...). Non-technical information is more dependent on context; I would suggest looking for a source when it's at all contentious, e.g. "The project release was delayed because one member converted to Scientology and tried to erase all our WIPs."

For #3, I personally don't mind this but others have disagreed (some examples are linked in a thread above, and maybe that's why you're asking...).

The general question about historical events is one we need to answer eventually, as the gamer community continues to migrate to chats, corporate servers, and other non-citeable locations. Journalists have written about 1980s arcade tournaments, where the "source" was a spiral notebook duct taped to the wall, so I assume it's possible. :)

Welcome, and uh, thanks for thinking about the big picture! MinimumJosei (talk) 11:17, 12 September 2025 (CDT)

I am not entirely sure how to answer #4. Maybe add a second column to the Levels section showing the map order for the remastered WAD?

For #5, I'm not sure if we usually link to Doomworld profiles. We have added links to people's official Twitch and YouTube channels in the past; I would say these are okay if they are active and have a number of followers/subscribers.

For #6, it sounds like they are noteworthy at a glance. If you're not sure, create a draft article in your userspace (like User:Zohayu/Jetx_121) so that we can see their contributions. Doom Wiki:Criteria for people articles may also be of some help. Gauss (talk) 11:44, 12 September 2025 (CDT)

Thanks for the welcome! I appreciate you both helping me out. Only started editing a week ago so I'm still learning the details.

I have a good idea of how to proceed with the edits now. The images I'll just upload manually as I work on each page.

Also put together a draft for the article I want to make on my user page, if someone wants to check it out. Zoyahu (talk) 13:12, 12 September 2025 (CDT)

1. With one screenshot per Doom 64 level, what are the other ~118 images about? ;-)
   Uploading can be automated via the MediaWiki API and a script, API libraries exist in many languages. This is what I'm doing via User:XymphBot, but a bot account is not required to use the API (that just flags edits so they don't clutter Recent Changes by default).
2. Sourcing remains preferred so that it can be verified by reviewers and looked at by readers who may be interested in more context surrounding the entered trivia/I&D fact. Entries shouldn't be too itty-bitty, but that is obviously subjective. But relevant/interesting tidbits are welcome, and if sourcing is not possible, then the next best thing is to put a description of its origin in the edit summary.
3. If the account name of a wiki editor matches the map author, then submitted trivia/I&D can usually be considered sufficiently sourced, unless the entry is entirely implausible. :)
4. The remaster flew under my radar because nobody mentioned it on the Beta 64 page yet, so that's the first order of business. The extent of the changes needs to be determined, both in map layout and secret sectors as well as things population. If significant on many maps, then a new WAD article with distinct series of map pages is best, like Going Down: Turbo and the Heretic remaster; otherwise the differences can be noted in the existing series, like Jenesis: Bethesda Edition and Judgment: Retrial. The latter is a lot more manual work, but better for the wiki as it doesn't duplicate the info that remained unchanged. All these darn re-releases in recent years cause a somewhat frustrating amount of extra wiki work, though. I will look into the extent of the changes this week, and decide.
5. Doomworld and Doom Wiki are considered one community, and profile links are normally not added to people pages (though over a dozen slipped in over time anyway). Notable platforms in good standing are always linkable. Web content creators should also be added to this table.
6. The informal guideline is to have contributed maps in at least two CPs what are notable enough to have their maps covered as well, along with a couple of other non-covered releases. Jetx_121 did that in one CP so far, but their standalone WAD and other work & video content bumps them over the (admittedly somewhat vague) threshold. So go ahead; but there should not be a map list for a WAD created mostly/entirely by a single mapper.

Hope that helps. --Xymph (talk) 04:49, 13 September 2025 (CDT)

Thank you for your detailed response!

As for the large amount of images, my bad, I should have been more clear with wording. I mean I have one image for each level for all the vanilla Doom 64 levels (40), but also for all the custom Doom 64 wads with articles on the wiki (Beta 64 with 32, The Unmaking with 40, Ethereal Breakdown with 32 and a few for Doom 64 Reloaded).

I was going to give them the same treatment as Dreamblood: put an image on every page (+ any for easter eggs) then put a 2x4 gallery on the main page.

Reloaded does not have individual map pages so I was just going to upload eight gallery images for it.

Zoyahu (talk) 06:33, 13 September 2025 (CDT)

Okay, all that will have to be done the normal way (manually) indeed. --Xymph (talk) 07:10, 13 September 2025 (CDT)

About #2, the impossibility of quoting from Discord -- something that I've seen used on some other wikis is simply uploading a screen capture of the relevant post. --Gez (talk) 01:07, 14 September 2025 (CDT)

I've considered doing that as well, but I thought people may not be happy with me uploading a ton of images with just discord messages in them.

For the Doom 64 WAD Dreamblood the author left comments on youtube I could easily refer to, so I'm thinking about alternate ways to source info similiar to that.

I've joked with people about doing an interview video on the easter eggs/references which might actually be the best way, especially for the megawads.

Zoyahu (talk) 07:35, 14 September 2025 (CDT)

Re. #4, Beta 64 was remastered fairly minimally, with minor or almost no changes in geometry and things population in many maps and more notable changes only in a handful. The main remaster aspect seems to have been pruning the excess duplicate secrets. So it will take a manual pass over all map pages to note differences, which I will do over the next 2-3 weeks as time permits. --Xymph (talk) 12:11, 15 September 2025 (CDT)

Upon further comparison, changes were so minor in most cases, that 'remaster' is a bit of misnomer; it's more like a v1.x update to the original. I've simply updated all pages, stats and map views to the new release, and added the CC64 map. Some have a new secret though, and Dynamo has no time to work on this for quite a while. Zoyahu, would you be able to write up the additional descriptions to reach them, and perhaps review the existing secret descriptions in case I made a mistake? --Xymph (talk) 10:49, 3 October 2025 (CDT)

Yeah, I can do that. My available time will be very sporadic for the next few weeks so it might take a bit for me to get around to it.

I think I'll play through all the maps again, check and update the secrets, and start making notes for the walkthroughs because I want to learn how to do those too.

But now that you've updated the map pages I will add the screenshots first. Zoyahu (talk) 02:10, 5 October 2025 (CDT)

I managed to find/update most of the secrets for Beta 64 and revised them for the first five maps. I took the liberty to attempt to make the terminology/wording consistent with how I've seen walkthroughs written, for example using in-game names instead of manual names. Some descriptions have been changed to describe level features to either add to or replace ones that relied on cardinal directions (something like "eastern part of the map" is not very clear and (IMO) relies on the wiki map too much, as the automap in Doom 64 rotates with you). Please tell me what you think of these changes. I also wrote a walkthrough for MAP01: Electric Moon (Dreamblood) which got me thinking that maybe we could create a small guide for writing up secrets/walkthroughs? I understand by their nature they are less strict/formal, but it seems useful to still have some loose guidelines or at least a few pointers listed somewhere.--Zoyahu (talk) 01:08, 16 October 2025 (CDT)

Good job on the secret updates and walkthroughs, keep the good stuff coming :) Regarding the guide, it has always been my impression that it's less about guides and more about finding people who actually have the time to commit to walkthroughs. I ended up doing a few myself but it's a ton of work so it's no surprise it's not as popular as secret walkthroughs. --Dynamo128 (talk) 15:40, 16 October 2025 (CDT)

Thanks! I guess you're right, the real barrier is all the time that goes into them. I'm planning walkthroughs for all the Doom 64 PWADs, I hope my my familiarity with them will speed up the process a little.--Zoyahu (talk) 23:28, 17 October 2025 (CDT)

Slow loading?

In recent days the Doom Wiki has been loading extremely slowly for me. Going to any page on the wiki means 20+ seconds of blank screen, then the page appears. I want to check if anyone else is having similar problems.

• Being logged in or out made no difference.
• Changing skins had no effect (I use Vector when logged in, but switching to the default Monaco did nothing).
• Using different browsers (Edge and Firefox) made no difference.

Other websites, including Doomworld, are not being affected. I have also not changed any preferences recently. Gauss (talk) 17:17, 15 October 2025 (CDT)

I have actually noticed this too. I'm aware there have been instances of when there's a 503 for the wiki as well as other bits of slow loading but this is probably the first time it has been a 24-hour occurrence (I started noticing the loading times yesterday night). No preference changes here either. Getsu Fune (talk) 19:05, 15 October 2025 (CDT)

I can confirm the slow loading. For me it's been an issue for at least a week now. It varies over the day. Sometimes loading is fast as it should be, then back to a crawl, or somewhere in between. But mostly on the slow side. There also seems to be an extended blackout period every few days that last for many hours at the time where the wiki will not load at all. --Gregor (talk) 20:19, 15 October 2025 (CDT)

I have the same issue with slow load times. I am using Brave, so it seems it's not an issue with any specific browser. --Zoyahu (talk) 23:04, 15 October 2025 (CDT)

Same here. Xymph told me that this is because of search bots (Google, Bing etc). And we can't block them without damaging our SEO (though I'm not sure why it is so important for free community wiki without any ads). --Nockson (talk) 01:02, 16 October 2025 (CDT)

This is not a user-side issue, the server has been struggling for the past two weeks. In particular MySQLd appears to be slogging for long periods of the day, pushing system load into the 4-9 range (normal is 1-4). I am monitoring every day, and have in the past blocked undesirable bots (i.e. AI leechers, SEO marketing bots, and anti-social media spiders), but lately there doesn't seem to be any unusual or high levels of requests. Yet the server cannot cope as well as it used to, and I have no idea why. I've asked Quasar to get Manc to look into it, hopefully they'll find a solution.

Btw, search engine bots (mostly Googlebot and bingbot) have to be allowed access, or our wiki's ranking would tank, and (even) more search traffic would divert to the old, commercial, non-community wiki. Also, those bots are generally well behaved (although bingbot used to be a bit aggressive until I increased its crawl-delay in robots.txt). --Xymph (talk) 04:40, 16 October 2025 (CDT)

Proposed changes to the listed port of Doom 64 WAD articles

Greetings! I am proposing changes to the listed port of several Doom 64 WAD articles. I think these updates would remove some ambiguity and make it more obvious how these WADs are actually played.

• Dreamblood lists "Vanilla Doom 64" as its port, but the author agrees it should be changed to "Doom 64 (2020 version)". (While the 2020 release constitutes as vanilla, "Vanilla Doom 64" can be interpreted as compatibility with N64 hardware, which is not the case: Dreamblood is made for the re-release specifically.)

• Doom 64 Reloaded also lists Vanilla Doom 64 as its port and should be changed to the re-release for the same reasons.

• The UnMaking lists EX as its port, but the author agrees it should list the re-release, as it's the main version and the most popular way to play the WAD. (I do plan to add additional info below stating it's compatible with EX/EX+, as they function with only minor differences.)

• Ethereal Breakdown lists EX as its port, but the re-release version of the WAD has always been considered the primary version. The EX version will also soon be outdated, as the re-release WAD will be updated to fix several issues, while the EX version will be abandoned.

• Beta 64 lists EX as its port. The remastered version is for the re-release only and will likely be the main way people play the WAD going forward, due to its greater accessibility and bug fixes. Because the original was entirely made for EX with no other versions developed alongside it, changing the port is debatable. Personally I would still change it to list the re-release instead.

Any thoughts? I checked to see if perhaps a page can list multiple ports, which seems not to be the case. --Zoyahu (talk) 02:41, 8 November 2025 (CST)

This seems very good to me. The current implementation of the port for Doom 64 was a bit undercooked and underdeveloped, so this should address that. --Dynamo128 (talk) 05:41, 8 November 2025 (CST)

Agreed. Also, {{wad}} supports a port2 parameter. --Xymph (talk) 05:53, 8 November 2025 (CST)