Doom Wiki:Central Processing

From DoomWiki.org

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

Archived discussions


Doomsday Wiki[edit]

The Doomsday Engine Wiki (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[edit]

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

competn[edit]

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[edit]

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

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

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

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

OpenGraphMeta SEO additions[edit]

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

  • Articles now have 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?[edit]

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

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

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

Hell Guard editor[edit]

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

Attribution question[edit]

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

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

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

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

latest archive.org wiki dump available[edit]

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)

FlaggedRevs configuration change proposal[edit]

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

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

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

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

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

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

Very, very, very slow.  It's a good question though, since the legacy pages could vanish overnight (again) and we'd like to have a plan for that.
IMO we should keep the 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[edit]

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

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

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

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

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[edit]

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?[edit]

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[edit]

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[edit]

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[edit]

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[edit]

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[edit]

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)
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[edit]

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[edit]

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.  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[edit]

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[edit]

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?[edit]

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)