Doom Wiki:Central Processing

From DoomWiki.org

Revision as of 07:39, 12 September 2022 by Xymph (talk | contribs) (Thing data tables)

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

The Doomsday Engine Wiki (https://dengine.net/dew/) is no more, replaced by a Doomsday Engine Manual (https://manual.dengine.net/). 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 dengine.net/dew 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)

2019

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

competn

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 https://www.doom.com.hr/public/compet-n/admin/incoming.log 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

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

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

  • Articles now have schema.org-compliant 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?

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

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

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 archive.org wiki dump available

I do this roughly annually, this is the third dump. https://archive.org/details/wiki-doomwiki.org-20190408 -- Shambler (talk) 07:52, 15 April 2019 (CDT)

Here's the dump for 2020: https://archive.org/details/wiki-doomwiki.org-20200703 -- Shambler (talk) 08:58, 13 August 2020 (CDT)

Here's 2021's dump. For the curious, the images (zipped) in 2017 came to 1.7G, and in 2021 they come to 3.9G. https://archive.org/details/wiki-doomwiki.org-20210705 -- Jdowland (talk) 04:29, 6 July 2021 (CDT)

Thanks. Yeah, new map views and screenshots galore. :) --Xymph (talk) 04:34, 6 July 2021 (CDT)

FlaggedRevs configuration change proposal

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

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 gamers.org 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

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)

I had forgotten that redirects were an exception to #6a, as described here.  IIRC they are rare, but my spreadsheet treated them as full-size pages, so I'll have to do an additional pass at the end.  Ryan W (living fossil) 17:39, 30 November 2019 (CST)

I haven't followed this process in detail, but in view of the "manually triaging 4000+ redirects" remark: would you need bot script assistance with that?
Btw, in item 7 above, instead of "=yes" you used "trivial=1" so far. --Xymph (talk) 03:11, 8 December 2019 (CST)
The offer is appreciated, but no, spreadsheet functions should handle it easily.  If any on-wiki task could ever be urgent enough that a script was required to bypass category links lag, this isn't it. :>
These steps may have been posted before actually looking up which boolean formats are supported currently.  0 and 1 are always safest.    Ryan W (living fossil) 14:47, 8 December 2019 (CST)

This should now be complete.  As noted above, here are my non-algorithmic taggings — the new parameter is often a judgement call, so I'm collecting these for easy review.

  • Move threads from non-trivial to trivial category (step 1): [1]
  • Move threads from trivial to non-trivial category (step 7): [2] [3] [4]
  • Tag non-trivial threads where the page was kept or later recreated (step 6a): [5] [6]

A very small number of cases were skipped because

  • the talk posts were so vague/tentative that I couldn't tell whether a change was seriously proposed;
  • only placeholder items like this were present, their fate having been decided elsewhere; or
  • they were in user space, where it's generally more trouble than it is worth to intervene.  (That said, the log seems to show every case to date being an obvious speedy anyway.)

I occasionally stumbled over case sensitivity and non-ASCII characters (which I don't recall being issues previously), so it's possible I didn't locate 100.00% of the threads, especially for redirects.

To be clear, this is a one-time job; I don't intend to chase everyone around waving the template.  For one thing that's irritating  :>  and quite far from mission-critical.  More importantly, people who close discussions are trusted to know the applicable process, even when they intend to deviate from it to serve common sense.

HTH/KUTGW everyone.  Ryan W (living fossil) 00:48, 9 December 2019 (CST)

Idgames template zoo, followup

I am starting to think about this task.  My first brainstorm is to leave IRC because it engenders rash promises.  :>

We currently have:

  • Template:Idgames (883 transclusions, 11 links)
  • Template:Ig (1117 transclusions, 4 links)
  • Template:Ig2 (2 transclusions, 5 links) Marked as deprecated in 2016.  Functionality is a subset of Template:Idgames.  Therefore, should be completely safe to replace.  Ryan W
  • (redirect) Template:Idgames2 (no transclusions, 2 links) This one is no longer used, so it can be a normal speedy deletion.  Ryan W
  • Template:Idftp (4 transclusions, 1 link)
  • Template:Idftp2 (2 transclusions, 1 link)
  • Template:Idgamesmm (6 transclusions, 3 links)
  • Template:Igmm2 (3 transclusions, 3 links) Replaced all four of these per Gez's assertions below, which no one seemed to dispute.  In passing, fixed a few 404s arising from treating DW's front end as a full mirror and appending extensions to the file= parameter, which doesn't work anymore if it ever did.  Ryan W

I don't have a proposal yet, but (per Death Egg's thread above) I tentatively believe that

  • a single template could support all features, using parameters like linkonly=
  • some mass edits will be slightly too large to do manually
  • we should excise Doomworld's ID numbers while we're here
  • listing affected pages is relatively easy with a maintenance category
  • any spidering must be heavily throttled to avoid pissing the webmaster off
  • after Doomworld's domain migration, the new template could be expanded to allow a front end URL (assuming those continue) and maybe even a /newstuff parameter
  • script development is a finite resource, so if it's not available right now, that's completely fine

Other contributors use these links far more often than I do, so hopefully they will share their thoughts here.  Thanks, Ryan W (living fossil) 23:51, 20 December 2019 (CST)

The first step should be to eliminate the little-used ones -- basically, everything that's not {{idgames}} or {{ig}}. This can be done manually, as there aren't that many of them. The {{idftp}} templates lost their reason to exist separately when the id FTP server went offline.
The second step would be to normalize on either idgames or ig. Since ig is the most used, I'd suggest using it as the baseline to shave off ~230 edits. This task would have to be made by a bot. Things to watch out for are the different default link text (pagename for idgames, "Doomworld/idgames" for ig), this behavior could be made conditional on the value of the linkonly parameter (if true, assume the default is dw/ig, if false, assume pn). --Gez (talk) 03:29, 23 December 2019 (CST)
Quasar listed some cons to IDs, which I agree are valid concerns, but having worked with the templates and their id=/file= parameters a lot, I feel some pros of IDs were underexposed.
Foremost is that ordering by ID results in approximate chronological order of files' initial releases. Approximate because this is not exactly by date, but when compiling Body of Work lists it does certainly help. And when a file is updated keeping the same name in the archive or with a version increment in its name, then its unchanged ID helps to keep it in order of original release – at the time of generating or verifying a works-list – while its updated timestamp does not. Conversely, a version increment in a name requires the file= parameter to be updated every time (as I do for every DMMPST release), which is less convenient than the static ID. These advantages are the reason I added the ID lookup in my listigf script rather than directly used the file paths.
But I can imagine that consensus is reached on the cons outweighing the pros. So if IDs are to be replaced then it would be helpful to keep some ordering ability with the alternative – although I have no idea how.
Anyway, id= parameters are (and were historically) used far more frequently than file=, and updates are thus needed on the majority of both idgames and ig template transclusions. To a script that processes both lists, if only to verify that some don't need updating, the number of entries is then the same. So I would suggest to use as template name the one that is the most general and clear. In that sense, I think idgames is a better choice than the somewhat cryptic ig (although there are the {{lc}} and {{wp}} precedents).
Ryan, what do you mean with "a /newstuff parameter"? --Xymph (talk) 11:15, 23 December 2019 (CST)
Ouch, please disregard /newstuff for now.  Structured data it is not.  :>
For chronological order, query the date field perhaps?  If it still works, it should be far more accurate, especially for old maps originally hosted elsewhere.
Short template names arose, at least in part, to reduce keystrokes during mass edits by humans.  Whether you agree or disagree with that goal, be aware it may be discussed again.  Ryan W (living fossil) 14:50, 28 December 2019 (CST)
For the ID parameter, I'd be tempted to keep it. I believe the template already prefers the file parameter if you give both, so the id parameter can remain as a historical note. Furthermore, ironically, the "modern" Doomworld interface uses it. For example, the Plutonia 2 path for the modern interface is <https://www.doomworld.com/files/file/15550-plutonia-2/> and, not coincidentally, that same number 15550 is its id in the old interface <https://www.doomworld.com/idgames/?id=15550>. Finally, there's the whole "/idgames protocol" thing, which again is based on numbers, and Plutonia 2's URL with that protocol is unsurprinsingly <idgames://15550>.
While we should definitely strive to put the real path in these templates, the numbers can be handy if we decide to update the output of the templates. For example, if we want to generate URLs for the "modern" Doomworld interface (perhaps as a consequence of the removal of the "legacy" interface). --Gez (talk) 06:50, 24 December 2019 (CST)
I tried it and file= indeed takes precedence if both parameters are present (in both templates), so that works for me too. Combining them in scripted updates should be pretty trivial.
Regarding "different default link text" which "could be made conditional on the value of the linkonly parameter", I don't think it's that easy. The two templates produce the following output on these parameter combos:
idgames w/o linkonly idgames linkonly=1 ig
title title at DW/IG title title
no title PAGENAME at DW/IG PAGENAME DW/IG
I'm not sure idgames linkonly=1 is ever used without a title parameter though. If not then emitting DW/IG in place of PAGENAME works, or if a few times then we could resolve those manually. If the PAGENAME output of idgames linkonly=1 w/o title parameter should remain available, then to incorporate the "no title" effect of ig, an archname=1 parameter could be used. Not very elegant, but anyway... food for thought? --Xymph (talk) 04:52, 28 December 2019 (CST)
A first incarnation of the idgamesLinks.php script written yesterday (on 1356 links in 884 pages) confirmed that idgames linkonly=1 is only used with a title (parameter). So the above table can be condensed to:
idgames w/o linkonly idgames linkonly=1
title title at DW/IG title
no title PAGENAME at DW/IG DW/IG
to combine both templates per Gez's original proposal. --Xymph (talk) 02:37, 30 December 2019 (CST)
I can revise conditional logic as needed, so please don't treat it as a design constraint.  ;>  I'm proceeding gradually because I want full backward compatibility, and for the script's actions to be deterministic.  It will take time to work through all cases, so I created this thread first, to ensure I didn't overlook essential conceptual points.
Regarding ID numbers: When the domain moves, ideally it should take at most one edit to unbreak all links.  That isn't possible with IDs alone if the legacy front end is dropped, as in 2017, so I agree with Gez about populating paths.  "Beta" URLs must be optional for the same reason: we can't expect to know their final format until they go live, and unless Ling shares his algorithm, I would be nervous about generating them automatically as Gez suggests.
I'm still pondering whether link format should have one parameter or several.  Multiple parameters would avoid conflations of logic like this, but might seem cumbersome to editors who use templates rarely.
FWIW, and thanks for spending some time with this.  Ryan W (living fossil) 14:50, 28 December 2019 (CST)
"That isn't possible with IDs alone if the legacy front end is dropped, as in 2017" – I don't get that concern. Consider what happens if you visit <https://www.doomworld.com/files/file/15550-nuts/>, <https://www.doomworld.com/files/file/15550-my-neighbor-totoro/>, or <https://www.doomworld.com/files/file/15550--/>. As far as I can tell, all that's needed to make a valid URL is a number, a separator dash, and then any other character. The server looks at the number part and redirects you to the "proper" address. --Gez (talk) 05:49, 29 December 2019 (CST)
That's true today, but immediately following the upgrade it was not.  Only after massive backlash were the alternate links enabled.  The webmaster is on record elsewhere as not prioritizing history preservation (example), so IMO we should plan for the next relaunch moving irreversibly to new URLs.  Ryan W (living fossil) 06:50, 29 December 2019 (CST)  Obviously I'd love to be wrong, and if you (or another with community standing) is feeling generous, you could end speculation by inquiring with the root users directly.  For most of us that's not an option and we have to treat browser output as a black box.  HTH.
What was broken was the old paths, but not the id. Knowing the id of a file and having only the modern interface lets you access it reliably, as I just demonstrated. The name doesn't matter for the new interface, only the id. For the id to no longer be valid, it'd take a nuking of the Doomworld database, in which case then yeah, they would become useless, but then the idgames would have to point directly to one of the mirrors instead of any Doomworld interface. --Gez (talk) 10:33, 29 December 2019 (CST)
Definitely agree on the last part.  Time permitting (which is for Xymph to decide of course), and after normalizing on one template, I suppose the bot could do something like:
  • If id= is populated and file= is not, retrieve the file path from the API and add it.  Then put the path back into the API to get the ID, and if it doesn't match, or if either call failed, set a parameter in the template to invoke a maintenance category for human review.
  • Same thing if file= is populated and id= is not.
  • If both are populated, put each into the API, and if both calls succeed and the returned values match, do nothing.  Otherwise, invoke the maintenance category (because a human must compare the package contents to the article's description).
  • Stipulating that the IDs have now been validated, follow redirects of the form https://www.doomworld.com/files/file/12345--/ to retrieve the beta URL for each reviews page, and populate that in the template call also (another new parameter).
  • Repeat all steps once a year in case of database hiccups, per the 2016 thread.
Regarding the future, again I hope you're right about everything, as you usually are.  The DSDA migration changed its backend and stopped assigning IDs to new mods.  Just saying.  Ryan W (living fossil) 17:23, 29 December 2019 (CST)
That should be feasible, except the part "to retrieve the beta URL for each reviews page, and populate that in the template call also". How do you mean this? --Xymph (talk) 02:37, 30 December 2019 (CST)

←←←←  At the risk of being pedantic, here's a real example:

* {{idgames|file=levels/doom2/a-c/cct}}

From the API, the ID comes back as

11694

(the documentation doesn't mention that ".zip" must be explicitly appended).  Per Gez above, it deterministically becomes

https://www.doomworld.com/files/file/11694--/

The bot pastes this into an imaginary browser location bar (it's possible in bash so I tend to assume a library exists :>  and observes it turn into

https://www.doomworld.com/files/file/11694-congestion-control/

therefore the current link is replaced by something like

* {{idgames3|file=levels/doom2/a-c/cct|id=11694|xaserurl=https://www.doomworld.com/files/file/11694-congestion-control/}}

which would possibly render as

Please don't feel you need to implement anything until a proposal is posted and undergoes a comment period.  For all I know, people consider the new URLs too tentative or redundant or navelgazing to include.  I am undoubtedly forgetting how to handle the first link intelligently (i.e. not sending all traffic to the same mirror).  Also the format in "body of work" lists is different and the regular contributors might want it to remain different after this update — apologies for totally overlooking that situation in the OP.  FWIW everyone.  Ryan W (living fossil) 05:30, 30 December 2019 (CST)

No worries, wasn't planning on steamrolling ahead until a good plan has been hashed out. :)
Re. your example, several observations/questions:
  1. I don't think a direct download link to any particular mirror (especially not one that died earlier this year) should be used. Even though the list of mirrors on the old interface site is outdated, at least it provides multiple working options.
  2. The old interface site shows the file path (here levels/doom2/a-c/cct.zip) as a string that can be directly copy/pasted on a file system level. Not sure how valuable that is to anyone else, but this field is invaluable to me because on my own Linux system I run a backup of gamers.org and thus an idgames mirror. I frequently use the direct path in commands like zipinfo/unzip and cat of the .txt file. On the new beta interface this Filename field is absent.
  3. The file= path should not have .zip appended, because that redirects to the legacy server with expired cert.
  4. What's Xaser's involvement with the new beta interface?
  5. Given that a properly constructed URL with ID already gets redirected, wouldn't it be easier to not require a parameter (like xaserurl) but just have the template produce the second link automagically? At least when manually using the template to make it less elaborate for the casual wiki contributor.
E.g. * {{idgames4|file=levels/doom2/a-c/cct|id=11694}}
which would possibly render as
For scripted updates to existing template invocations, the processed URL could indeed be included to show the official URL when hovering over, and save a redirect on the DW server. --Xymph (talk) 16:27, 30 December 2019 (CST)
(2) Wiki contributors have always been asked to template any external link that can be templated, so yes, that's just you.  :>  If those paths disappear during the domain move and we can't find an easy workaround, you will have to discuss it with the DW staff.
(4) (5) The parameter name was mostly a joke; I endorse the "automagic" approach for improved usability.  At the time, I interpreted statements such as this to mean Xaser had some authority over the URL changes.
(1) (3) These also sound like improvements.  I guess if I assume without direct evidence that arbitrary changes could occur during the domain move, it's equally valid to assume there is no timetable to start the move, thus we can fairly design our templates around the current setup for now.  (I wasn't suggesting ".zip" could be included in template calls idgames transclusions, as indeed it was never designed to be, only in API queries.)
HTH / KUTGW.  Ryan W (living fossil) 12:20, 18 January 2020 (CST)
P.S.  the processed URL could indeed be included to show the official URL when hovering over  — This seems of limited use to the reader if they can't follow the link without editing the page (but maybe with a modern mobile browser such things are easier).  It's also technical debt if the URLs again change non-deterministically.  But I don't feel strongly; if you really want hover text, I'll implement it.  Ryan W (living fossil) 12:30, 18 January 2020 (CST)

Please see merge logic (first draft).  It isn't finished: it only covers Quasar's initial request, without any of the refinements above.  I continue to assume that, before the bot does anything, I'll have to revise Template:Idgames to support one or more new options without corrupting any existing links.  Still thinking about how to do so.  Thanks, Ryan W (living fossil) 19:41, 22 January 2020 (CST)

The more I think about it, the less I like the idea of merging ig and idgames. Looking at some of the examples on that first draft, worry for the size of a link-template-intensive page like list of notable WADs. --Gez (talk) 10:51, 23 January 2020 (CST)
ig has only 16 uses there; the other links are generated by Template:Notable and thus need no markup updates.  If such "alternate" links are intended to occupy a standard position, you could even replace most/all with optional parameters to Template:Notable (thereby changing the page's nesting depth, which has a greater effect than byte count alone).
Regarding more typical cases like this, in a vacuum I agree that code shouldn't get longer and longer over time.  But we aren't in a vacuum because each scripted task has a specific goal: forcing every possible upstream data set into the same uniform rendered format.  My reading of Wikipedia's template history suggests that the inverse 80/20 rule is occurring: the more real events we document, the more the logic must expand to accept the associated diversity of input.  Ryan W (living fossil) 18:43, 23 January 2020 (CST)
Hi. I've only been peripherally aware of this and that's a lot of reading above so apologies if this has already been brought up. I'm in favour of keeping file IDs since as Xymph noted it's useful for approximating a chronological order of WAD releases on mapper articles and the like, however... Doomworld's beta interface was introduced in March 2017, files uploaded before then have the same ID on the beta interface as the legacy one, but that is not the case for files uploaded since. For example: MAYhem Purple, uploaded in November 2018 has ID 19233 on legacy, but 19249 on the beta. --Eris Falling (talk) 15:49, 23 January 2020 (CST)
Ewwwwwwww!  I thought that had been fixed for a year.  It seems like a serious issue when such links are added by humans, because the bot won't know which interface they had copypasted from.  For the scripted links, I don't suppose there's some computation to map one ID value to the other, which Ling doesn't want you to talk about for security reasons?  :7  Ryan W (living fossil) 18:54, 23 January 2020 (CST)

Bypassing front end?

The functionality of the "id Software FTP" templates is not duplicated by the main templates, because the former hotlink to a file at a specific mirror, rather than a landing page with a selection of mirrors.  A live example is here.

Discussion so far (including previous threads) suggests to me that the landing page is superior, despite the extra click:

  • Any individual mirror can experience downtime, or may be too distant (via network topology) from the reader.
  • The archived reviews provide additional insight about the file which would be too "chatty" for our article.
  • For backward compatibility, the main template would have to begin supporting the hotlinking and the choice of mirror.  The link counts above imply this would be considerable effort for a rarely used feature.  After implementation, it would be tedious to keep all transclusions updated each time a server moved or died or lost its certificate or whatever.
  • The FTP protocol itself is deprecated [7].  Even if some mirrors retained it, hotlinks would eventually break for readers with newer browsers, and might harm our search rank by being non-secure.

I've never used these templates, so I don't want to unilaterally dump them.  Does anyone definitely agree or disagree?    Ryan W (living fossil) 23:47, 18 January 2020 (CST)

IMO they can be safely dumped. As noted, they originally served to link to an archive that no longer exists. There's no reason anymore to preserve this link to the past, they can use the same {{ig}} template as the others. --Gez (talk) 09:03, 20 January 2020 (CST)

Codex entries

So do we break down and keep these, or go through and paraphrase them all into prose about the levels? They do contain a lot of information that we are currently missing in any form so I'm certainly not just wiping out the revisions immediately. --Quasar (talk) 19:23, 12 February 2020 (CST)

I have paraphrased or disbursed info from all of these as of this evening. --Quasar (talk) 21:47, 16 March 2020 (CDT)

Problem edits 20200303

The following edits are verbatim copyvio and based on leaked information from unintended early publication of the Dark Horse book, The Art of Doom Eternal:

  • Maykr: [8]
  • Dread knight: [9]
  • Arch-vile (Doom Eternal): [10]
  • Marauder: [11]
  • Gladiator: [12]
  • Revenant (Doom Eternal): [13]

--Quasar (talk) 07:24, 3 March 2020 (CST)

We can (and should) remove the offending bits. Does anything else need to be done first? --Gez (talk) 09:56, 3 March 2020 (CST)

Review backlog

For those that are curious I'm quite busy trying to enjoy Eternal while still having duties at my job. This is why the review backlog is getting very large. Note that many of the currently unreviewed revisions contain verbatim copyvio from codex entries. All of this needs to be rewritten. --Quasar (talk) 03:17, 27 March 2020 (CDT)

Carlos filter

These edit attempts triggered the abuse filter to block an IP address and warn another. I've reverted the block because I don't see any vandalism in these contributions. I'm not sure on which word the filter tripped. --Gez (talk) 10:11, 30 March 2020 (CDT)

The "ass" in Carcass appears to trigger it but it was supposed to require another profanity on the line as well. I've axed that part of the rule entirely since I can't figure out my own logic any more at this point. --Quasar (talk) 12:37, 30 March 2020 (CDT)

Discord

Hello everyone, I am CIA391, most well known from a wiki called Halopedia. I am here to propose Discord for use with the wiki as I believe it may be very beneficial to the progress of the Doom wiki, and be easier for new users to use and discuss stuff with other users and admins.

In my experience on Halopedia, Discord has really helped the wiki shine over the last few years. Getting in new editors, discussing projects fast, and well in general just building a community round the wiki and the franchise we love the information on. I also find its very accessible compared to IRC, users when given the chance chose Discord over the existing IRC channel we had set up.

This is a few discords that have done quite well for being wiki discords just to show a few that have had benefited to the discords existing. This is merely me showing that discords based on Wikis can work. And well there is many more.

And well I found a few folks are really finding Discord to be a great place to discuss Doom at the moment, so I just thought it would be a great chance to get a Doom Wiki Discord started. Regardless thanks for reading my suggestion.-CIA391 (talk) 10:25, 1 April 2020 (CDT)

Hi there CIA, and thanks for stopping by the Wiki. I agree that Discord is a great tool for discussing things over. That being said, DoomWiki at the moment does not use one, nor does it use IRC - Reason being is that many users have their own time tables, being spread all over the world. The users with full editorial rights are only a bunchful, and DoomWiki tries to adher to the Wikipedia standards for a lot of the time - Mostly in terms of presenting encyclopedic knowledge. I hope this helps! -- Redneckerz (talk) 16:23, 12 May 2020 (CET)
Actually, #doomwiki is actively used, albeit in fits and spurts. --Xymph (talk) 09:57, 12 May 2020 (CDT)
Perhaps the fact this is news for one of our recent heavy contributors explains why #doomwiki is so quiet…
FWIW, I'd probably, reluctantly, connect to a Doomwiki Discord if someone created one. But I'm a grumpy old person and I'm quite happy with IRC.
Shambler (talk) 09:02, 13 August 2020 (CDT)
Personally I never liked things like IRC or AIM, and Discord just seems to me to be the same thing but as a proprietary format hosted on a corporation's own servers. --Gez (talk) 19:08, 12 May 2020 (CDT)
Hi CIA391, welcome to the site.
The idea that Discord needs promotion seems odd to me.  :>  Hasn't it been the fastest-growing outlet for several years?  Nowadays, I would think anyone seeking a fan community would look for social media feeds first, before a forum or wiki.
Regarding Doom specifically, I mostly agree with Redneckerz and Gez.  The wiki is not primarily about building a community — we had preexisting locations for that, such as doomworld.com and iddqd.ru — it is about the final published product, about research and accuracy.  Responding to anything in real time is usually harmful, a form of technical debt.  It's always better to think and investigate before posting, sometimes extensively, to ensure another user doesn't have to repeat the work later.  As said above, some wiki editors use IRC regularly, but many do not, and it doesn't seem to hinder anything (excepting rare cases where some urgency can exist, e.g. server downtime, harassment complaints).
More broadly, many active doomwiki.org contributors are also free content adherents.  Some don't even use Windows.  The accessibility you mention is arguably a bad sign, because it means there's lots of money for software development, and where do you suppose that comes from?
All that said, I have heard of successful Discord projects within the Doom community (Joy of Mapping, DSDA3).  For instance, gameplay content and walkthroughs for our newer games still have a lot of holes, and I suspect those players tend to use the wiki less often than our retrogamers do.  If someone wanted to coordinate that content addition, it would be a substantial tangible benefit to doomwiki.org.  Just don't expect to receive any sort of linking or other formal approval in return, for the reasons given above.  HTH. Ryan W (living fossil) 13:32, 5 June 2020 (CDT)

ZDoomGL (v1)? ZDoomGL (Kokak)? - Seperating the two versions

I am about to overhaul the ZDoomGL (v1) page before starting on Timmie's version. Because that will involve creating a new page, i like to ensure which terminology is considered acceptable Therefore i present this in a general page first, seeking other editor's opinions.

A talk page was created yesterday here - ZDoomGL talk after i changed the ZDoomGL page to ZDoomGL (v1). Despite doubts, i pushed this forward without prior discussion, resulting in the above page discussion. I should have made a Talk page first.

My intent was (and is) on providing clarity through the introduction of the (v1) (in brackets) and (v2) monikers, despite such not being historically 100% accurate See the Talk page for more info as to why i prefer (v1) and (v2).

Summary:

  • I derived at the given name by the following: Kokak's version targets ZDoom 1.x, Timmies ZDoom 2.x. So naturally, v1 would be a good reference (For us) that its based on ZDoom 1.x. It should be short as to not detract too much from the name, and functional - so v1 to me was the natural deduction. To make it more distinct, i felt the brackets made the most sense there. I felt this was the most elegant way of labeling them with the least amount of harm done.
  • Gez suggested to differentiate the two as ZDoomGL (Kokak) and ZDoomGL (Timmie).
  • One compromise would be to reference it as ZDoomGL (Kokak) | ZDoomGL so that it still shows as ZDoomGL in the text. On the mainpage, it would obviously be ZDoomGL (Kokak).

If this has to be discussed in the Talk page instead, then i apologize for bringing it here.

Open to hear opinions. -- Redneckerz (talk) 11:10, 12 May 2020 (CET)

Speedrunning record tables

Previous discussions here, here and here; starting a new topic in case the 2019 topics ever get archived.

I've commenced work on scripting speedrunning info and record tables from Compet-n and DSDA. Focusing on the former now, as a sufficiently usable and documented API for the latter appears to be still some ways off.

Planned phases:

  1. Add/update speedrunner (stub-)pages for linking from record tables (mostly completed).
  2. Update the category tables for the IWADs (completed).
    Since Compet-N allows only seven PWADs, it seems sensible to compile the same tables for those too. But that would result in huge articles with gazillions of links, which may be unwise from usability and/or technical viewpoints. Any suggestions on how to structure them; perhaps into separate articles per category? perhaps collapse them by default, like on Linedef type? – or confirmation that it's no problem?
  3. Update record tables for the WADs as whole (completed).
  4. Update record tables for all individual maps (completed).
  5. Update record tables for all pertaining speedrunners.

Feedback welcome. --Xymph (talk) 05:31, 8 June 2020 (CDT)

Full support from me — should greatly improve an underdocumented area.  These phases appear exhaustive of the data we've ever seriously considered adding.  I endorse Eris's remark that map automation is a victim of its own success: any other procedural update must become automated, because humans can't keep pace.  :D
It sounds like #3 and #4 are two steps each, because COMPET-N vs DSDA output will be disjoint.  A vaguely related thread is here.
Is #2 even worth doing?  I'm not a fan of articles simply parroting another site without adding any original insights or integration, which we then have to keep synced forever.  The lists were created in January 2005 when our scope was still totally unclear; we aren't normally bound by nebulous precedents from that period.  IMO the long-term goal should be replacing each with an explication of routing principles, any tactics specific to the style, and a historical summary including key innovators and landmark runs.
If we must have lists, there should be no technical issue regarding size.  This still loads OK with templated links at varying levels of recursion (which these won't have) and many more rows.  Others will need to say how many views/searches the pages receive in their current condition, and whether Google interprets hundreds of similar links as a parked domain.    Ryan W (living fossil) 13:16, 8 June 2020 (CDT)
Yes, #3/4/5 will have separate tables per demo repo. #5 would probably remain limited to the IWADs, like they are now.
Your goal for #2 sounds worthwhile, but could be a long way off. Meanwhile, if there are lists, they might as well be updated after all these years. For me they would be a good target to learn and understand how the Compet-n database tables fit together, and to get my scripts and queries correct. If and when the category articles get rewritten per your proposal, the record tables could always be moved into adjacent or hierarchical subpages. --Xymph (talk) 09:21, 10 June 2020 (CDT)
Fair point — I hadn't thought about the instructional aspect.  :>
Limiting #5 to IWADs would have been controversial a decade ago.  I guess we'll find out whether that departed with Win9x.  :>  To first approximation, I'd agree with people who say IWAD records are far more impressive due to the larger player pool.  OTOH a few were still submitting PWAD improvements last I looked.  HTH / KUTGW.  Ryan W (living fossil) 11:31, 10 June 2020 (CDT)

← ← ←
Step 2 is ready for deployment, pending the outcome of some data discrepancy checks by Fx, so I proceeded with #3 first. The script for #4 is nearly ready too, but meanwhile I'd like to solicit input on the table style for #5. Invented by Jartapran it uses layout/styling/coloring that I can reproduce in the next script, but if there is to be any discussion about refining (or even overhauling) it, then I would rather have that now before I program something that needs to be changed soon after. Personally I'm fine with maintaining this table style, but if anyone isn't then this is a sort of "speak now or forever hold your peace" moment. ;) --Xymph (talk) 07:42, 21 June 2020 (CDT)

More progress already!  Regarding #3, the bot has already passed all the unit tests I could find in my old notes, so I guess I approve?  (People should examine my original implementation [14] before deciding I know what I'm talking about.  :7
Regarding #5, other related suggestions are here, here, here , and here .  Arguably they are irrelevant now that a solid prototype exists.  :>  Still thinking about the layout details though.    Ryan W (living fossil) 10:01, 21 June 2020 (CDT)
I'm fine with the table style (FWIW — definitely no graphic designer), and I dimly remember a consensus forming for this layout among users actually helping with tabulations back then.  With that said, some miniscule suggestions:
  • New COMPET-N presents episode runs and movies as "map slots", rather than entire distinct categories as implied previously (archived 🏛).  Would it therefore make sense to tack those records on to the bottom where present? [15]
  • Should an "all time" column be added to the summary table?  It feels misleading in some cases to simply report a zero, e.g. Yonatan Donner.
  • The tables are unevenly spaced in some skins.  (Ignore this one if it's my calcified browser acting up.)
  • Change runsstyles in the footnote.
HTH, and thanks again.  Ryan W (living fossil) 17:13, 22 June 2020 (CDT)
I'm not sure about the coloring -- when I see tables with green, orange, and red elements in them I just intuitively read the colors to mean "good, average, bad" which isn't really the theme going for here. It'd help if each of the IWAD had a strong connection to one color, but all the title screens are dominated by the color red while level color themes are all over the place. That said I'm not personally interested in the speedrunning side of things, so feel free to ignore this objection. --Gez (talk) 04:19, 23 June 2020 (CDT)
I see your point. With the script advanced far enough the generate tables – more work is needed to make it update player articles – it is very easy to produce color scheme variations, thanks to schemecolor.com. Since the original scheme is somewhat pastel-like, I searched for similar schemes, and also collected some via the site's Related feature. Please everyone (not only Gez) review and let me know what you like/dislike. Colors from different schemes can be combined into a new one, in new orders. If you want me to try them, list the four color values and I'll add them to the page. --Xymph (talk) 08:01, 10 July 2020 (CDT)
Given the deafening silence I compiled a scheme with the following "rules": no red/yellow hues; each of the four colors sufficiently distinct from the others and from the gray header and white totals footer, without jumping out of the page; the same group for Doom1&2 and another for Final Doom, with the latter (more difficult?) title in each group having the darker hue. The resulting scheme uses green and blue. One or more colors may be insufficiently distinct for viewers with some form of colorblindness, but that is a separate topic.
If no objections pop up soon, I'll be using this scheme for all speedrunners (with records on the IWADs). I've also dropped the spaces from the category totals ("4/1/0/4") so they fit without wrapping. --Xymph (talk) 06:47, 13 July 2020 (CDT)
Hi, Xymph! Seeing that you're in the process of automating this stuff, I wanted to point out that there was an addition in the charts of Jim Leonard (Xit Vono). The total amounts of current records are listed below the heading (UV speed 17, NM speed 41 etc.). If people find that feature useful, I guess you might want to add it to the script. Whatever you do, thank you for your work on this area! :) (If this thing has been brought up already, my apologies. I haven't had much time to follow the wiki lately.) --Jartapran (talk) 13:03, 13 July 2020 (CDT)
Hey, thanks for the heads-up! While I had looked at that article, so far I glanced over that one additional total per category, given that Adam Williamson('s records table) is my primary guinea pig. :) I would eventually have noticed when updating/diffing Xit Vono's tables with my script output, but it's better to take into account now already. --Xymph (talk) 14:12, 13 July 2020 (CDT)

When the fastest posted demo on COMPET-N is from Competition Doom, do you intend to link that in place of a DOS demo?  It's such a rare situation that I assumed "yes" because you'd otherwise be generating an entire parallel set of tables.  But that's only an assumption until I ask.  :>  HTH.  Ryan W (living fossil) 09:07, 28 June 2020 (CDT)

CnDoom is a separate database, so I wasn't considering it until now. I do have access to it and see it holds only 105 rows. Queries can't stretch across databases but I could combine entries in the script(s), although it would be a bit awkward. However, I have no idea whether that would make sense, due to unfamiliarity with the whole competition scene. So I'd like to see more input and have to consult with Fx before attempting that. --Xymph (talk) 10:27, 28 June 2020 (CDT)
Fx let me know (but seems too shy to post himself ;) ) that he's not in favor of mixing CnDoom in with Compet-n, is concerned that it might confuse people. So I am not investing further time/energy into this for now. --Xymph (talk) 04:25, 18 July 2020 (CDT)

The "uncompleted" footnote becomes inaccurate when extended to multi-map recordings.  I see the view that category rulesmaps exited are independent data dimensions, and in fact on DSDA3 they are, but in COMPET-N they aren't (and weren't under AdamH).  So I propose changing it to

No qualifying run verified and published, as of the most recent Compet-n database update.

If the same footnote is to be used for both databases, then even this is misleading because DSDA verification is largely crowdsourced.  Webmasters perform some basic validations, but then an apparently acceptable demo can circulate for years before becoming contested.  Whatever text we do adopt for DSDA records, it should be templated, so the bot need not roll out future tweaks.  :>

Assuming this overall premise is valid, I don't have a strong opinion on whether you should actually omit the additional rows.  If the required booleans are in a SQL table, the bot can incorporate them automatically, but if not, I'd understand if you didn't want to maintain them yourself (I'm not even sure how human users are notified of updates, aside from seeing a new forum thread on doom.com.hr).  And because fx02 has the final decision on said flags, nothing stops him from sanctioning the other categories someday, if enough runners participate.  :>

P.S. Thank you for retaining the Final Doom complevels footnotes also — that still confuses people, 20+ years later, and heaven help anyone whose connectivity is too slow to post questions to social media.  HTH / KUTGW!  Ryan W (living fossil) 10:46, 28 June 2020 (CDT)

\o/ \o/ \o/ \o/ \o/ \o/ [16]  Ryan W (living fossil) 13:48, 6 July 2020 (CDT)

Thanks. A nice side-effect of the scripts were two-way consistency checks: not only did the scripts update various manual data entry slip-ups on the wiki (like swapped digits or MM/DD), but they also revealed some inconsistencies and data mishaps in the main database, which Fx fixed last week(end). --Xymph (talk) 08:01, 10 July 2020 (CDT)

← ← ←
To allow further review of the current state of the script, I've updated the test article. The proposed color scheme is in full effect, including the initial totals table to visually link up those numbers of the listed records. The totals per category are added above each column per Jartapran above. And the new PWADs subsection contains a brief summary of a player's other records.

Naturally it's possible to generate a complete table layout (with 7 colors) like for the IWADs, but for some speedrunners (especially Xit Vono, with 249 entries here) that would make for a very long section. Given concerns that the wiki should not completely reproduce the data/statistics of another site, I thought a brief summary may be a suitable compromise, but I'm open to reading other ideas. --Xymph (talk) 15:47, 13 July 2020 (CDT)

Additions and updates to record tables for Compet-n players are completed, which wraps up the bulk of this project (until DSDA's API emerges, anyway). I see I missed some suggestions/questions by RyanW from June 22:
  1. "Compet-n presents episode runs and movies...tack those records on to the bottom where present" - I summarized those in an "Other records" section analog to the PWADs records summary.
  2. "Should an 'all time' column be added" - I see your point but have no idea how to collect all-time records, distinct from the number of submitted demos.
  3. "tables are unevenly spaced" - I saw that spacing depends on the window width: the wider the more evenly spaced they are. Not sure what, if anything, can be done here.
  4. "runsstyles in the footnote" - Flew under my radar but now updated in the script, so it'll be used in the next update sweep (whenever that'll be).
--Xymph (talk) 04:25, 18 July 2020 (CDT)

Changing Template:Cite web

We have these fantastic templates which organize and format information about online sources.  I'm trying to extend the functionality as shown here (hopefully that's clear).  All four can take a bare URL as a parameter, so this should apply to all four.  The test template is being used here.

This might seem too minor for Central Processing, but I didn't create these and haven't used them often, so I'm announcing it for two reasons:
  • If I screw up, this could mass-create 404s which aren't immediately noticed.  I don't think I have screwed up (thanks to ExpandTemplates) and don't demand anyone drop what they're doing to test it, but if you agree about the risk, then I encourage you to examine my version.  I won't bring it live unless there's feedback or loud silence.  :>
  • Templating these links may be incorrect journalism.  Style guides tell us to cite the link we actually used, not an intermediary or container (e.g. URL shortener, media embedded in a tweet).  If a domain moves, then the link shown in the article will differ from what was accessed on the date given.  I can see both sides of this but precedents exist, and we have had so many headaches with link rot that I must support modularization.  If someday we need the absolute URL at the time of insertion, we can recover it from the corresponding template revision in 99.9% of cases.
So yeah, let me know if I'm worrying about nothing.  :>  Thanks, Ryan W (living fossil) 05:54, 8 June 2020 (CDT)
Seems good to me. --Quasar (talk) 13:20, 25 June 2020 (CDT)

Update: This is now live.  Unable to visualize the entire "phase space" of citation styles plus combinations of incomplete parameter calls, I tested further with individual articles already using these templates heavily.  To my astonishment, it seemed to work.

If anyone's references begin outputting broken links or other strangeness, just revert me and we'll figure it out later. [17] [18] [19] [20]  Thanks.  Ryan W (living fossil) 16:22, 28 June 2020 (CDT)

Handling BTSX release as official add-on

For the Official add-ons release of BTSX, the mod's name was shortened to "BTSX" and all of the level names were changed. I am going to strongly suggest that we create redirects for (and appropriately document) these names and not separate articles, as they are not new maps, they were just renamed—for that release only—to avoid legal issues. --Quasar (talk) 13:23, 25 June 2020 (CDT)

Redirects created; documentation added. --Gez (talk) 17:43, 25 June 2020 (CDT)
Thanks a ton. --Quasar (talk) 17:55, 25 June 2020 (CDT)

"Marked spots on the map" not displaying on wiki?

Hi all,

I'm not sure if it's my browser or I'm just blind, but on the pages for the Doom II levels, the letters which are supposed to display on the maps (and are referred to in the walkthroughs) are not actually there on the map.

For example, here is the map for level 13 of Doom 2: [21]. I don't see any letters there, even though the walkthrough makes explicit reference to them when discussing the secrets.

By contrast, the Hangar map has obvious letters on the image matching the walkthrough text: [22]

Were new images uploaded and the next just never updated to match, or anything like that? Obviously it's not that much of a big deal since I can figure out where the secrets are by just using noclip and process of elimination, but it is strange.

70.30.107.183 14:20, 3 August 2020 (CDT)

Nothing's wrong with browser or eyes. Walkthrough, i.e. spotted, maps have been created for nearly two dozen maps (Doom E1, E2M1-5, E2M9, E4M1, Heretic E4M1-5, Doom64 MAP01, and Oniria), using various approaches. It's a very time-consuming process of which so far no part has been automated, although an investigation into those possibilities is still on my to-do list. So this continues to be a human effort which, in this particular aspect of the wiki, happens to occur few and far between. --Xymph (talk) 15:13, 3 August 2020 (CDT)

Voodoo dolls listed under statistic things for deathmatch mode

Example article: MAP02: Down Through (Sunlust)

This may be grasping at straws, but for the generated level stat tables I noticed the "Voodoo doll" row can appear in the Deathmatch table. Should this be excluded given Doom doesn't use the player 1-to-4 starts in deathmatch mode? i.e., Voodoo scripts and crusher / barrel instadeaths don't work.

I noticed the "Cooperative start" row only appears in the Cooperative table so excluding "Voodoo doll" in Deathmatch table makes sense.

... unless a source port exists that allows voodoo dolls to work when the -deathmatch parameter is enabled? I'm not aware of any. --Afterglow (talk) 20:31, 15 August 2020 (CDT)

Hello.  Sounds like a reasonable question, given that keys are already omitted.  Is this the original discussion?  Maybe nobody thought of it at the time.    Ryan W (living fossil) 13:00, 17 August 2020 (CDT)
No, I don't think that ever came up during development & discussion. But it makes sense, so implemented and tested now. Will update all pertaining map pages. --Xymph (talk) 05:38, 20 August 2020 (CDT)

New category suggestion

I am thinking about adding Weapons by type under Weapons, and then creating subcategories there such as Pistols, Rifles, Shotguns, Rocket launchers, Crossbows, etc. The already-existing Demonic weapons would also move under that subcat. Any feedback? --Quasar (talk) 03:35, 31 August 2020 (CDT)

Sounds fine. So the category would work across games, e.g. the crossbow category would include Heretic's ethereal crossbow, Strife's electric/poison crossbow, and perhaps DE's ballista? I think the same idea could also be applied to monsters. --Gez (talk) 04:50, 1 September 2020 (CDT)
Yeah that's the gist of the idea. --Quasar (talk) 05:42, 1 September 2020 (CDT)
If there are enough articles, sure.  I guess there's a small chance they attract paragraphs of headcanon.  :>  Would existing subcats move to "Weapons by game"?   Ryan W (living fossil) 11:17, 2 September 2020 (CDT)
No problems there. Will add a level of additional granularity. May take some time to get right but if things have to be moved i can always take a look at that. --Redneckerz (talk) 14:25, 2 September 2020 (CDT)

Let's see what we have to work with:

Game Pages in weapons category
Doom BFG9000 Chaingun Chainsaw Fist Pistol Plasma gun Rocket launcher Shotgun Super shotgun
Canceled Assault rifle (Doom) Dark claw Machine gun (Doom) Probjectile Spray rifle Unmaker
Dooom 64 Demon Key Unmaker
Doom RPG Axe Dog collar Fire extinguisher
Doom 3 BFG 9000 (Doom 3) Chaingun (Doom 3) Chainsaw (Doom 3) Double barrel shotgun (Doom 3) Fists (Doom 3) Flashlight Grenade Ionized Plasma Levitator Machine gun Pistol (Doom 3) Plasma gun (Doom 3) Rocket launcher (Doom 3) Shotgun (Doom 3) Soul Cube The Artifact
Doom 2016 BFG-9000 (Doom 2016) Burst rifle Chaingun (Doom 2016) Chainsaw (Doom 2016) Combat shotgun Demon control grenade EMG Mark V pistol Fist (Doom 2016) Frag grenade Gauss cannon Grenade launcher (Doom 2016) Heavy assault rifle Hellshot Kinetic mine Lightning gun Pistol (Doom 2016) Plasma rifle (Doom 2016) Reaper (weapon) Rocket launcher (Doom 2016) Siphon grenade Static cannon Super shotgun (Doom 2016) Tesla rocket Vortex rifle Weapon modification Weapon upgrade
Doom VFR BFG grenade launcher Grenade launcher (Doom 2016)
Doom Eternal Ballista BFG-9000 (Doom Eternal) Blood punch Chaingun (Doom Eternal) Chainsaw (Doom Eternal) Combat shotgun (Doom Eternal) Crucible (Doom Eternal) Doomblade Flame belch Frag grenade (Doom Eternal) Heavy cannon Ice bomb Pistol (Doom Eternal) Plasma rifle (Doom Eternal) Rocket launcher (Doom Eternal) Super shotgun (Doom Eternal) Unmaykr Weapon modification Weapon upgrade
Hacx Cryogun Hoig Reznator Kick Nuker Photon 'zooka Pistol (Hacx) Stick Tazer Uzi
Heretic Dragon Claw Elven Wand Ethereal Crossbow Firemace Gauntlets of the Necromancer Hellstaff Phoenix Rod Staff
Hexen Arc of death Bloodscourge Firestorm Frost Shards Hammer of Retribution Mace of Contrition Quietus Sapphire Wand Serpent Staff Spiked gauntlets Timon's Axe Wraithverge
Strife Assault rifle Crossbow Flamethrower Grenade launcher Mauler Mini-missile launcher Punch dagger The Sigil of the One God

So besides the already added pistols, shotguns, double-barreled shotguns, and demonic weapons categories, here's what else we could have:

  • Utility weapons: Probjectile, Flashlight, Ionized Plasma Levitator , Fire extinguisher
  • Improvised weapons: Flashlight, Fire extinguisher, Dog collar
  • Melee weapons: Fist, Axe, Fists (Doom 3), Fist (Doom 2016), Blood punch, Crucible (Doom Eternal), Doomblade, Kick, Staff, Mace of Contrition, Spiked gauntlets, Hammer of Retribution, Timon's Axe, Punch dagger, Hoig Reznator
  • Rocket launchers: the many Doom variants, and Mini-missile launcher
  • Grenades: Grenade, Frag grenade, Siphon Grenade, Demon control grenade, Kinetic mine, Tesla rocket, Frag grenade (Doom Eternal), Ice bomb
  • Grenade launchers: Grenade launcher (2016), BFG Grenade Launcher, Grenade launcher
  • Plasma weapons: the plasma guns/rifles, Stick
  • Electric weapons: Static cannon, Hoig Reznator, Tazer, Arc of Death, Crossbow
  • BFG: BFG9000, BFG 9000 (Doom 3), BFG-9000 (Doom 2016), BFG Grenade Launcher, BFG-9000 (Doom Eternal)
  • Flamethrowers: Flame belch, Flamethrower
  • Crossbows: Ethereal crossbow, Crossbow
  • Magical staves: Hellstaff, Phoenix Rod, Serpent Staff
  • Magical wands: Elven Wand, Sapphire Wand, Bloodscourge, Wraithverge
  • Magical gloves: Dragon Claw, Gauntlets of the Necromancer
  • Magical swords: Crucible (Doom Eternal) (arguably), Quietus
  • Spells: Firestorm, Frost Shards, Arc of Death

... I'm not entirely sure what to do with the various rifles/machine guns/chainguns. Light automatic weapons and heavy automatic weapons? Also I kind of feel like the Soul Cube, Unmaykr, and Sigil of the One God could have a category for them, "alien super-weapons" maybe? I don't like that name but they're not demonic. Also I don't know what to do with most of Hacx's weapons. They're various kinds of ill-explained energy weapons (photon zooka shoots photons? So it's just a torchlight?) --Gez (talk) 04:52, 3 September 2020 (CDT)

If we were to go by the taxonomy of real-world weaponry (which is not necessarily a serious suggestion, but let's see where it leads), the various semi- and fully-automatic weapons would fall into the following categories:
  • Long guns (this would actually by definition also include shotguns)
    • Machine guns (definition: fully automatic)
      • Rotary cannons / Gatling guns
        • All chainguns
      • Submachine guns (fully automatic; using pistol-calibre ammo IRL)
        • Machine gun (Doom)
        • Machine gun (Doom 3) - Based on IRL classification of corresponding similar RL weapon FN P90
        • Machine pistols
          • Uzi
    • Rifles
      • Selective-fire rifles (multiple firing modes)
        • Carbines (short barrel)
          • Heavy assault rifle
          • Heavy cannon
        • Assault rifle (Doom) - NB: technically. You can let off for one round that's more accurate, or hold down for auto.
        • Assault rifle (Strife) - Similar. Burst fire or automatic.
        • Burst rifle - Explicitly calls itself this accurately
Well you can see one problem of course is that Doom has never actually contained a chain gun. So that might confuse people. There is also a confusing border, even in IRL, between machine guns and selective-fire rifles at times, to where the categorization might become vague or a topic of conflict. None of this is to mention the dreaded classification of "assault rifle" which is all over the place. --Quasar (talk) 08:26, 3 September 2020 (CDT)

Codex material final straw

So I'm busy for a couple of days and I come back to the entirety of the '16 and Eternal codex contents having been up since the 8th, and not a single one has even been flagged for speedy delete on copyvio grounds, let alone anything done about it. I've really had it with this. I can't put up with it, it is an unacceptable risk to me personally. This is a warning to all mods that I require support with moderation of contents on these grounds, or else there are going to be major changes required to how this site works with respect to new or unregistered contributors. --Quasar (talk) 16:59, 11 September 2020 (CDT)

Special thanks to User:TheGreenHerring for stepping up to help with cleanup. --Quasar (talk) 17:19, 11 September 2020 (CDT)
Note - I was super frustrated when I made the above post; please don't take it too seriously. I appreciate everybody and apologize for letting myself get too worked up over something that was fixable w/o a major fuss. --Quasar (talk) 20:48, 16 September 2020 (CDT)

Page merges in light of The Ancient Gods, Part One

Given that the DLC confirms beyond all doubt that Samuel Hayden and the Seraphim (as well as VEGA and the Father) are the same person, should we merge their pages together accordingly or allow them to remain as separate pages? I'm not sure which course of action is preferable, given how much of the pages will need to be rewritten either way.--Newlydoomed (talk) 14:21, 20 October 2020 (CDT)

And having seen several of the Codex entries as well as some confusion on my part after learning that "Seraphim" is the name of a species rather than an individual, I've had to go back and do significant rewrites to several articles. Any help that could be given would be greatly appreciated. --Newlydoomed (talk) 12:30, 22 October 2020 (CDT)
I am personally opposed to this because of the narrative complexity and the already sufficient length of each article involved. If someone has come to the wiki curious about Samuel Hayden, having played Doom '16 only, then they will simply be confused if they arrive at Samur Maykr and will have to put in serious effort to try to separate the two subjects. This isn't even getting into the real-life elements of characterization that are a bit inconsistent either. Some things clearly changed during Eternal's writing phase from what was originally intended. This is best captured if the article takes what '16 says about Hayden at face value and doesn't try to reinterpret it into the lens of what is added later. --Quasar (talk) 05:37, 26 October 2020 (CDT)

wiki upgrade

this wiki lacks various useful templates such as the mention and notification template found in wikipedia i think.Mussharraf Hossen Shoikot (talk) 07:22, 1 December 2020 (CST)

Hello!  It's usually possible to fork a Wikipedia template in some form, but it might not remain useful if it relies on specific characteristics of Wikipedia, such as MediaWiki extensions, categorization rules, or a huge editor base with many active admins and bots.  Do you have specific examples in mind?    Ryan W (living fossil) 18:50, 2 December 2020 (CST)
Ryan W the {{ping}} template also known as {{u}} templateMussharraf Hossen Shoikot (talk) 06:29, 3 December 2020 (CST)
Those seem to be discussion utilities and that's not the primary purpose of this wiki. Editing someone's talk page already gives them a notification, by the way. --Gez (talk) 07:51, 3 December 2020 (CST)
On Wikipedia, "notification" implies the added features of the Echo extension which we don't have.  So {{ping}} wouldn't function, and {{u}} would create a link without pinging, which seems pedantic to me, but certainly not against any rules.
Technical limitations can be overcome if someone throws enough code/cash at them, but I agree with Gez that the issue is qualitative.  On-topic discussion is good.  Rapid discussion, and pushing specific users to follow a thread, are social media conventions not aligned with this site's philosophy.    Ryan W (living fossil) 11:48, 3 December 2020 (CST)

Mediafire

So apparently for the coming new year, Mediafire's resolution is to delete all the old files. We have a few links to content hosted on Mediafire, this content is going to be dead links soon. --Gez (talk) 08:21, 19 December 2020 (CST)

Okay, I found 10 and 7 links to them, with some overlap and in one case (AIRSTRIP.ZIP) a mirror of a file still available elsewhere. Two (EtD1Setup.exe and resurge_map15_redkey.lmp) are already missing, I downloaded the others for safe-keeping. What would be a suitable hosting solution for the unique ones? --Xymph (talk) 08:49, 19 December 2020 (CST)
AIRSTRIK being mirrored on "redarchive" makes me think we might ask Redneckerz to host them? --Gez (talk) 10:36, 19 December 2020 (CST)
I covered AIRSTRIK on the DRD Team mirror primarily because of its rarity, so if the Mediafire mirror goes into flames - Well, there is a back up. Same for The Stick Figure which i believe i have backed up aswell. As for the other Mediafire links: Ill be glad to re-host them on DRD Team/RedArchive. I can put them in a special DoomWiki map for that purpose. Is there anything else required besides re-hosting and re-linking? --Redneckerz (talk) 12:06, 19 December 2020 (CST)
That would be great. Can't think of anything else, that should suffice. --Xymph (talk) 12:49, 19 December 2020 (CST)
Just checking them out, those PlayStation Doom files are going to be troubling with several 100 megabytes a pop. My little DRD Team is/was used for rather files - Rather 20-30 megabytes at most instead of 200-300. I am not sure if that holds up - I have to check my limitations. Ill download them eitherway so i can always upload them but those files might be a problem given their size.--Redneckerz (talk) 13:00, 19 December 2020 (CST)
Some of the others are large too, their combined size is 1.9 GB. So if your server is that limited, it would be a problem, yeah. Then you could cover just the other files and we'll look for another solution for those 6 psx ones. --Xymph (talk) 13:16, 19 December 2020 (CST)
It should be alright. I just saved them all and ill sync them on the FTP somewhere tomorrow. Ill let you know here if this succeeded. If i have to be frank, the PSXDoom stuff does come from a group whose works, impressive as it is, isn't the most organized, to say the least.--Redneckerz (talk) 15:59, 19 December 2020 (CST)
Mirroring and replacement of affected links is now complete. --Redneckerz (talk) 14:23, 20 December 2020 (CST)
Wow, thanks all!  This is how wiki collaboration is supposed to work — matching up resources with issues.  Ryan W (living fossil) 14:56, 20 December 2020 (CST)

Copyright vios round 2

I have fully returned. It may be no secret that I was growing frustrated with the rate of incoming contributions that were not carefully sourced. I am currently auditing the backlog of things that need my review and as a result I have identified a few images that require handling ASAP. These are especially some full-page (or near) scans from the Dark Horse Books Art of Doom Eternal; it's a minor miracle I have not received a takedown notice for these. Another I suspect comes from there but have not confirmed; either way the image is unsourced and thus doesn't meet our policy requirements. Round 3 will come if needed and will be added here as I continue reviews. Sorry in advance to anyone who might feel I'm being a "bad guy" by doing this; laws are only getting more draconian by the day—the US Congress just rammed through a bill that can let people sue you for up to $30k just for uploading images like these—and we cannot risk the entire site over some book scans. --Quasar (talk) 23:43, 27 December 2020 (CST)

Current problem articles/files

  • File:VariationsPalma.png
  • File:ConceptPraetor.png
  • File:DoomSlayerConceptArt.jpg
All three images deleted, per the reasoning given. —The Green Herring(talk) 00:28, 28 December 2020 (CST)

Broken links to doomedsda.us

We don't know the exact volume (Wayback Machine scrapes files occasionally) but anecdotal evidence is discouraging.  Here, for example, 8 of 8 links have expired.

AIUI a complete solution requires further web development, but here are some band-aid ideas.  I will be glad to implement them if people agree, excepting #4 which might be too large:

  1. Temporarily invoke Template:Frozenlink within Template:Dsdaftp, with hover text directing readers to the generic DSDA item in "External links"
  2. When Template:Dsdauser and Template:Dsda2user are used together, and the first represents 100% redundant content, remove it (example)
  3. Hope that archive.org re-enables deeplinking when their bandwidth issues subside, and retarget certain links there (example).  While not my primary goal, that feature WAS WORKING the day I tested it
  4. Peripheral mass edits to reduce 404s:
    (a) Replace bare links to zip files with Template:Dsdaftp, so any remediation propagates automatically
    (b) Update links of the form [http://doomedsda.us Doomed Speed Demos Archive] above map record tables
    (c) Remove the dummy string {{competnftp|**|**}}.  Now that pwad records have rolled out, such links are vanishingly unlikely to be used
    (d) List invalid Wayback Machine links generated by Template:Dsda, Template:Dsdauser, and Template:Dsdauserp (example)
    (e) List usages of Template:Archived link containing bare links to doomedsda.us

P.S.  None of this was caused by the automated tasks in the above section, which look great in my limited review so far.  :>  Any feedback or additional proposals appreciated!  Thanks, Ryan W (living fossil) 16:14, 3 January 2021 (CST)

Didn't reply sooner but have been working on this in tandem with the map/WAD records since last year, and I think everything is sufficiently cleaned up.
  1. Templates Dsdauser and Dsdauserp have archive links and are only left on user articles when the user has a reasonable number of demos on the old site (typically only FDA entries) that aren't on the new site, and a user profile (which the new site doesn't support). This covers item 2 above.
  2. Dsdaftp (with archive link) is only still in use for the Plutonia 2 FDA demos. This negates the need for item 1.
  3. All direct file links to old/new sites have been templated (item 4a). This also includes the old ftp://.zip stub and competn.doom2.net links. And also almost all Compet-n links, btw.
  4. Item 4b was covered by the scripted updates, no more external links.
  5. 4c ditto, though there is no working query to confirm that because of the asterisks.
In my experience with archive.org links, there is no need for further effort on items 3, 4d, and 4e. Please let me know of any stragglers. --Xymph (talk) 11:08, 29 July 2022 (CDT)

UAC Handbook

Hi there. I own a copy of the UAC Handbook second-hand. Not sure where it originates from, but I'm assuming a promo pack for DOOM (2016). As it is a rarity, and as it doesn't appear to be transcribed elsewhere, would it be allowed to be transcribed on this wiki (copyright infringement barring)?

If so, I'd be more than happy to help contribute to a page if one were to be created and initially set up (I'm not entirely sure about the creation and formatting procedures). Also, whilst I don't have the means to scan the booklet, I can take reasonable-quality images if required.\

P.S.: just found this article which may be a good reference to link to in a potential page created on this wiki.

--Rezalon (talk) 03:05, 25 May 2021 (CDT)

That's very interesting and I wasn't even aware it existed prior to this. However as you deduced we can't transcribe the entire booklet due to copyright. We can however describe it thoroughly in text and provide front/back pictures. A full description would be something like Doom instruction manual, or something less in-detail is also of course acceptable. --Quasar (talk) 07:26, 25 May 2021 (CDT)
Done the basics here. Someone else should be able to provide categories and other stuff I'm not fully aware how of adding. --Rezalon (talk) 22:41, 25 May 2021 (CDT)

Should we replace the old Cacoward image with the one seen on Cacoward 2018?

While browsing Cacoward 2020 looking for "mini mod safari" to search some cool stuff from ZDoom forum, I noticed something different, it seems they replace (or remake) the gold Caco image. So, I go to the previous Cacoward and notice the new Caco was first use in 2018. So should we replace the old Caco with the new one? Because Doom Wiki still use the old one —The preceding unsigned comment was added by Lokbustam257 (talkcontribs) .

With links, this is easier to follow: our award image, used in the {{wad}} template, originated here; the new image is here. I'd say that yes, we can update to the current version. Or even, get fancy in the template and use it only from 2018 onwards. --Xymph (talk) 03:08, 8 June 2021 (CDT)
With no further discussion or objection, this is done. --Xymph (talk) 10:03, 23 November 2021 (CST)

How to get article name changed?

I'm assuming only admins can do this at the moment. If so please hmu on my talk page pls but i'll probs contact an admin Kuresed (talk) 02:41, 30 October 2021 (CDT)

If Relic can send me a private message on Doomworld to confirm this is not someone pulling a prank, I can take care of it. --Xymph (talk) 04:12, 30 October 2021 (CDT)
Reverted, for no response in two weeks. Either this was a prank by an unknown nickname, or it is entirely unimportant to the real Relic, and the rename wasn't necessary after all. --Xymph (talk) 04:50, 13 November 2021 (CST)

DSDA records tables

Previous discussions here, here, here and here; starting a new topic in case the 2019/2020 topics ever get archived.

After covering Compet-n last year, I (finally) have time/energy/inspiration to turn some long-desired attention to DSDA -- partly prompted by Gauss' recent heroic efforts to manually update/verify map records. The initial version of dsdaMapBot.php is working, but I figured I'd bring up a few choices and caveats before plowing ahead full steam.

  1. In the table header category column, Compet-n tables use "Run", while the skeleton (as generated by DMMPST) used "Style". I will be using "Run" from now on.
  2. Based on Eris Falling's sandbox I'll include NoMo as a main category. Further DSDA categories NoMo 100S, Stroller and Collector go into the Miscellaneous demos section/table if present, otherwise that entire section is omitted. We could also make a different choice, e.g.: include all 12 categories in the main table. Or include the original 8 categories, and the newer 4 only if present. What do you think?
  3. Category 'Other' is ignored, it's just not practical to do anything scripted with that. I am using the only available API endpoint to fetch the record in each category which returns one entry for Other anyway. Further API development is not expected anytime soon.
  4. This also means any manually constructed tables like for Doom E1M1 cannot easily be preserved (unless all categories go into the main table and the Misc section can be left alone). Those are very rare so it's not going to be a problem anyway, as all bot-edits are viewed and manually approved anyway. And see the next point too.
  5. For the 11 WADs covered by Compet-n, it might make sense to also include DSDA tables, but then we need to decide how to structure the (sub)sections for script-wise edits to remain practical, and the 'verified' datestamp unambiguous. So for now I won't be touching these.
  6. The bot updates will also address some of the broken link issues listed above, like the DSDA title, old DSDA templates/bare links, and dummy competnftp templates.
  7. The current script already omits NM100S if the map article's Secrets section has no #-bullet entries, but auto-omitting rows in other situations -- like proposed by Eris Falling -- is going to be difficult. can be accomplished with per-map configuration flags in the .ini files, a variant on the one already in place for maps with secret exits.
  8. The API call does not return any notes, so we could chose to discard the Notes column. Not sure how much existing info we'd lose that way; Gauss recently made a point of noting v1.2 usage for KDiZD demos, but since that is the latest version I'd say this can safely be dropped. There may be more, and useful, examples, but I'll only encounter them once I start crunching WADs.

Any input/votes/opinions? --Xymph (talk) 13:06, 23 November 2021 (CST)

Some thoughts, I might have more later:
  • Regarding point #2, I've seen a few NoMo demos but none from the other categories (at least based on the few WADs I've gone through), so I'd support the suggestion to make NoMo a main category (I imagine with a link to no monsters mode) and leave the others in miscellaneous.
  • Regarding point #8, demos can have notes attached to them (see MAP21 from 1klinecp as an example) but I don't know how those are added in. Also, this particular demo is in the Other category.
  • As an aside, I never include records that have been flagged as dubious. If they are to be added, I feel they should be noted as such in the Notes column. Gauss (talk) 16:45, 23 November 2021 (CST)
The NoMo link is already in, see the 1klinecp map01 example link above. There are notes on non-Other demos too sometimes, but we'd have to find one that is the record to see if it gets returned in the API result before I will be able to include the correct field in the table. And the API returns "the" record for a category so I'd expect dubious ones to be skipped.
Re. #2, I'm leaning towards including everything in the main table, the 4 new categories only if they exist. On DSDA they are all together in the categories list, no distinguishing in two groups, so why should we? And on the wiki, the Misc. demos section can then be used for highlighting manually selected demos that are not a record, like with E1M1. So by default the section would not be present, which reduces stubbiness in map articles. And it solves the scripting trickiness of updating or preserving the Misc section. The datestamp then goes below the main table in "Current records", like for Compet-n. Actually, I can also update those tables to include NoMo if it exists. --Xymph (talk) 04:39, 24 November 2021 (CST)
Some exploring shows that not only the IWADs but also several PWADs like Icarus: Alien Vanguard, Plutonia 2 and Hell Revealed II have maps with Misc.demos sections that were manually compiled (e.g. TAS entries). So the approach outlined above is necessary to permit scripted updates that leave those sections alone, and I'm moving forward on that premise.
Meanwhile the script can do a few more useful things, as illustrated by the latest test updates.
  • Records can be returned by the API because they are cross-listed from another category even if they are not visible in DSDA's default view. The script detects this and adds a note, so now there is a use for that column as yet. The row could be italicized like on DSDA, but that seems excessive here.
  • Players without a wiki page are linked to their DSDA demos list.
  • NoMo, NoMo 100S, Stroller and Collector categories are listed only if there's a record, and the first (or only) occurrence of NoMo is wikilinked.
  • If the main table remains empty, 'data' in "The data was last verified..." refers to nothing, which is a bit odd. In that case, the string becomes "The (absence of) data was last verified..."
  • The "Miscellaneous demos" section is removed if it contains only empty row(s). If it contains a row now moved into the main table, it will have to be deleted manually. If preserved with other manual data, "Demos" in the header is lowercased if necessary, and direct links to the old DSDA site are replaced with {{dsdaftp}} (which itself should eventually point to archive.org, I guess).
I'll probably make further tweaks as I encounter new situations not yet taken into account. Any feedback so far? --Xymph (talk) 10:33, 26 November 2021 (CST)
I've looked at the linked test updates and I like what I see! I don't really have anything to add to the approach already outlined (which I agree entirely with), just a minor suggestion: list NM100S on the table as NM 100S, to better match the style for the other non-NoMo categories (skill level and name of the category separated by a space).
To clarify one doubt that has been raised, I believe dubious/cheated records are not returned by the API, as evidenced by the difference between the default view and the leaderboard view, for example. --Andromeda (talk) 07:42, 27 November 2021 (CST)
Space added (in the script). It was a Compet-n convention, but I found it a tiny bit jarring in DSDA context too.
Yes, the API call returns the Nevanos entry. Thanks. --Xymph (talk) 07:55, 27 November 2021 (CST)
Home stretch: Heretic and Hexen support were added, as well as skipping NM 100S if there are no secrets, and everything except UV speed/pacifist if there are no monsters either. For maps with secret exits the second occurrence of the relevant categories (UV speed, NM speed, Pacifist, NoMo, Stroller, and the Heretic/Hexen skills) is not wikilinked -- also added to the Compet-n script.
For the WADs added today, the demo tables have already been generated along with Heretic's first episode, and everything looks ready to (rock 'n) roll. --Xymph (talk) 15:32, 28 November 2021 (CST)
A feature I'd like to see in the future would be tables for movie runs, like on the Hell Revealed page. Nonetheless it's nice to see this being rolled out for the level pages at long last, thanks for the effort in automating this! --Andromeda (talk) 09:31, 19 December 2021 (CST)

← ← ←
The initial pass to update map pages is complete (I think), apart from the 11 WADs that already have Compet-n record tables. Here a second, DSDA section can be added as was already done manually long ago for one map. From the perspective of sections within the page, it would then make sense to rename "Current records" to "Current Compet-n records". However, that requires also updating the anchors in the map links on mapper pages. While all this can be mostly done script-wise, it's still quite a lot of work for 118 compet-n players. So, any agreement/disagreement about this approach?

After that, adding episode/DxAll runs to WAD pages is also on my to-do list, but it may take a (long) while before I'll get around to it. --Xymph (talk) 05:24, 22 February 2022 (CST)

DSDA records were added yesterday to all map pages for the 11 Compet-n WADs, and the Compet-n headers/anchors updated. --Xymph (talk) 02:57, 25 February 2022 (CST)

← ← ←
Daily wiki activity finally slowed down enough again to resume and finish development of the movie run records script, and all WAD articles for which they exist have now been updated with the table. Please let me know if you find any errors. This applies in particular for non-standard Doom II episodes. Normally, episodes 1/2/3 contains MAPs 01-10/11-20/21-30 but sometimes a WAD defines its own (smaller) episodes, and then the DSDA episode records cover those smaller map ranges. So far I've found this to be true for The Alfonzone, Judgment, Scythe X, and Valiant. If I missed any, please let me know as well so the script can be improved.

One more note about map records: some maps have one secret that is "impossible to miss" (e.g. the first or last sector the player has to move through). This implies categories NM 100S and NoMo 100S are identical to NM speed and NoMo, respectively. But I don't know if DSDA considers the categories equivalent in such cases, and drops one (presumable the latter). So this is not handled automatically in the dsdaMapBot script, like it drops NM 100S if there are no secrets. This may change upon feedback. --Xymph (talk) 05:46, 29 July 2022 (CDT)

Essentials of a map page?

I was wondering if there are any special requirements needed to be able to fill a page on a map and have it removed from the map stubs category. One of my long term goals is to populate/expand the pages of my favorite maps (especially 1994 WADs) and I was wondering what is considered necessary for a page to not be a stub. When I write for a map stub, I tend to focus on: 1. walkthroughs 2. gallery and 3. descriptions. Thanks to the monumental efforts of Getsu Fune, a good number of maps already have their secrets completed; adding the secrets plus the points I mentioned is what I, personally, would consider as a well filled page. - Endless01 (talk) 03:50, 7 February 2022 (CST)

I also consider the walkthrough to be vital for "de-stubbing", not least because it puts the other parts of the article (points of interest, secrets, screenshots) in context. Gauss (talk) 04:59, 7 February 2022 (CST)
I'm using the rules enforced by the destubMaps and restubMaps bot scripts, which I run occasionally (as they take a long time). So you don't need to actively worry about forgetting to destub sometimes. --Xymph (talk) 05:54, 7 February 2022 (CST)

Mapping themes

I was thinking about some ideas for future articles around Mapping themes. Now that we have a few, it's a great start that and, I think, helps readers tremendously, especially when the maps are categorized correctly with their specific theme. It's often a bit difficult to find specific maps, so this is a great way to organize maps.

I was thinking in the future, we could create articles for the following topics:

  • Outdoors/Nature/Landscape map (I'm not sure which term is more suitable, so I put those three for the moment).
  • Horror map
  • Winter/Snow map
  • Desert map
  • Cyberpunk map
  • Space map
  • Castle/Fortress map
  • Industrial map
  • Heaven map
  • Surreal map
  • Plutonia-esque/Plutonia styled map

Of course, some of these could be considered subtropes. For example snowy and desert can be part of outdoors/nature/landscape, and this can also have more subtropes, like the Egyptian map being a subtrope of the Desert map, etc.

This, of course, would be a long term goal with contributions from anyone here.

Oh, and I was also planning to create a main article for Mapping themes, and put some concepts about it, design tips and the list of themes. That way users can search for the main article in the searchbar, and fall into the rabbit hole of mapping themes ;)

What do you think? What other themes could be added? - Endless01 (talk) 01:07, 23 March 2022 (CDT)

The themes I was thinking of doing to round things up are:
  • E3 style (just because there are E1, E2, and E4 styles)
  • Gothic map (think Gothic DM, Crucified Dreams, and perhaps also stuff like Crusades and maybe also some of Hexen)
  • Medieval map (think Heretic E1 towns and anything else that seeks to depict a medieval Europeanish aesthetic -- by opposition to Egyptian/Mesoamerica themes or the modern look of City maps)
  • Space map (Vrack & co, anything set up on a spaceship or space station)

Other themes that may work are:

  • Asian (or East-Asian) map. For stuff with a Chinese/Japanese/Korean aesthetic, like Japanese Valentines for example.
  • Cyberspace map. Stuff that emulates visiting a cybernetic environment, like some of the Hacx maps but also VR: The Internet Machine or MAP31: Cyberwar 7734.
  • Flesh map/Meat map (think Cyb's Freaky Colonoscopy, or MAP20: The Mouth of Madness and its followups)
  • Scaled map/shrunken player map: maps that depict gigantic versions of normally smaller objects. Like rat solitaire or some of the maps from Mandrill Ass Project.
  • Plutonia style (to go along with the episode styles, and it's a popular one -- more than TNT style)

--Gez (talk) 09:55, 23 March 2022 (CDT)

Doom 3 screenshots

Some screenshots from Doom 3 are of a low quality and resolution. Two questions:

  • Is this a copyright issue or something similar, or can those screenshots be replaced with better ones?
  • Is it okay to use BFG Edition screenshots when the difference is minimal? (For example, in weapon pages.)

--Kyano (talk) 17:10, 10 April 2022 (CDT)

Which ones, for example? Define 'low' and 'better'?
There are some guidelines re. image quality, but I see plenty 640x480 Doom 3 screens in our archive, and that is not too low, if that's what you mean. Their purpose is to illustrate encyclopedic information about games, not to show off stuff in glorious 2560x1440 or what have you. Such screens merely take up more disk space than necessary (and we're starting to run low). I'd limit replacements to something like 800x600 - 1440x900.
But yes, a screenshot can be replaced by a similar scene under the same {{Doom 3 screenshot}} license. A different scene is probably better added as a new screenshot. As for the BFG Edition, I don't know. --Xymph (talk) 03:26, 12 April 2022 (CDT)
For example File:Chainsaw_d3.jpg is of a very low resolution and has dark lighting, making the details of the weapon very hard to see. I have seen several images that are similar in quality. Also, I disagree that low resolution screenshots are good enough for Doom 3; because of the dark setting of the game, many things are hard to make out at low resolutions. Doom screenshots on the other hand usually have high contrast and weapons, monsters, etc are much easier to see. I am not saying that we should be uploading 4K png files for the reasons that you have mentioned, but 1080p screenshots should be acceptable.
I asked about BFG Edition because it works better on modern machines and it would make it easier for me and others to take screenshots. --Kyano (talk) 05:40, 12 April 2022 (CDT)
Yeah, that one and similar tiny shots can be replaced. I suppose there is precedent for 1920x1080 too, as long as reasonably sized (but smaller) shots aren't replaced just for the sake of that resolution (which take up 800-1500 KB each). Lack of disk space will become a real problem eventually, given the absence of response to calls for a Linux admin to help Quasar with server maintenance and (eventually) migration.
If BFG/original edition differences are minimal, I guess such shots are acceptable, but I'd really punt this topic to someone more knowledgeable about it. --Xymph (talk) 06:46, 12 April 2022 (CDT)

Question about protocol for editing a page that's about me

Hi! I used to go by a different handle and noticed that there is a page about me that uses my old handle and I would like to update it. The problem is, someone else has also used this handle and a couple maps are included on the page that were by that other person. The page in question is https://doomwiki.org/wiki/Nomad

I contributed to all of the projects mentioned except the two maps in A.L.T., and was not the Nomad involved in "Clan [B0S]." but otherwise the information is accurate. As I noted, I'd like to update this with my new information (as well as potentially some new map contributions) but I don't want to just erase the other Nomad's information. What should I do in this situation? Annunakitty (talk) 16:51, 18 May 2022 (CDT)

The correct and simple solution is a new mapper article with your works. --Xymph (talk) 11:27, 19 May 2022 (CDT)
Yo! Thanks so much! I see you added my ASS maps too, thanks again :) Annunakitty (talk) 12:36, 19 May 2022 (CDT)

What about gkrellflynn?

It’s a krell for gkrellm (a graphical side monitor) that show Flynn’s head. The more the processors work, the more Flynn’s head is injured. Where should be categorized an article about it? Ducon (talk) 13:26, 26 July 2022 (CDT)

Playtester category

Some playtesters in the Doom community do a lot of work to ensure maps are decently balanced and playable. While their portfolio of work may not be to the same degree as mappers, modders or source port authors, I feel that there should be a place where prominent playtesters could be added, in recognition of their contributions.

You may want to sign yourself, Gibbon ;) But ill just repeat what i said on Discord. I agree, some playtesters do a lot of good and useful work in the community. But if this is your only credit, it is a little bit thin, in my opinion. --Redneckerz (talk) 17:15, 12 August 2022 (CDT)
I think the main distinction is that mappers, artists, coders create something, while play/code-testers "merely" help them to improve/debug those creations. Their contributions are of value to projects, sure, but I feel that there is little value to the wiki in listing these contributions here too. The projects' documentation should do that, and wiki cannot and should not need to completely cover every little detail too. Notability, however hard to define, remains an important factor for the wiki.
Also, given the wide variety of completeness and formatting in said documentation, and in the release process of many projects, it is already challenging enough to track mapping/artist/etc work on the wiki. So whatever the outcome of this discussion, personally I won't be investing any effort into tracking testing work too. --Xymph (talk) 06:43, 19 August 2022 (CDT)

Thing data tables

This is a follow-up to the original topic in 2016. The welcome slow pace w.r.t. new PWADs in recent weeks finally allowed me to resume development of my INFO.c tools. The planned implementation of generating the information in wiki-ready tables (using the same templating approach as in DMMPST) now works for DMINFO, and various samples are collected here. In comparison with the existing tables you'll notice some fields don't have a value, that is because some cannot be determined from the INFO.c and related data (alone), but the tool takes creating the tables for monsters, weapons, and items as far as it'll go automatically. The remainder will have to be added manually, as usual, and thus no additions/updates will happen via a XymphBot script.

The same is planned for the Heretic one (HTINFO), and then for Hexen and Strife where plenty thing data tables don't exist yet. I'll certainly encounter some unexpected situations there (because of the variety in weapon and monster behavior/data) but bridges can be crossed one at a time.

Changes versus the existing tables:

  1. The layout of the three monster tables/columns is now done with standard col templates instead of the custom table that made the whole thing more complex to edit manually.
  2. The thing type, mobj/enum, appears-in fields are now consistently present in that order, usually first in the table. Only for weapons they are, as before, preceded by the weapon-specific data. Should the three rows go first there too?
  3. In 2016 we discussed showing the flags field in hex and/or decimal, and it (finally) occurred to me that the simple solution is to list both on separate lines in that cell (not comma-separated in one line).
  4. I've merged the flags list table for monsters into the main table as I didn't see a real need to keep it a separate table, and the layout is cleaner this way. Description lengths vary, but it shouldn't be problem to have in them the right column of the main table.
  5. The flags field/list are now included in the weapon/item tables too. Is that okay?
  6. The weapon Sound row moved below the Sprite row, that seems a more logical order.

Please share your answers/feedback on the above. --Xymph (talk) 12:38, 11 September 2022 (CDT)