Doom Wiki:Central Processing

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

Heretic/Hexen capitalization issues

Cf. archive for context of the below wrap-up.

Wrap-up

To recap, we agreed on the following changes (partly reusing & expanding Nockson' original table):

Heretic/Hexen renaming consensus
Current name	New name	Use in text
Heretic weapons
Staff	Staff	staff
Elven Wand	Elven wand	Elven wand
Ethereal Crossbow	Ethereal crossbow	ethereal crossbow
Dragon Claw	Dragon claw	dragon claw
Hellstaff	Hellstaff	hellstaff
Phoenix Rod	Phoenix rod	phoenix rod
Firemace	Firemace	firemace
Heretic ammo
Wand Crystal	Wand crystal	wand crystal
Crystal Geode	Crystal geode	crystal geode
Ethereal Arrows	Ethereal arrows	ethereal arrows
Quiver of Ethereal Arrows	Quiver of ethereal arrows	quiver of ethereal arrows
Claw Orb	Claw orb	claw orb
Energy Orb	Energy orb	energy orb
Lesser Runes	Lesser runes	lesser runes
Greater Runes	Greater runes	greater runes
Flame Orb	Flame orb	flame orb
Inferno Orb	Inferno orb	inferno orb
Mace Spheres	Mace spheres	mace spheres
Pile of Mace Spheres	Pile of mace spheres	pile of mace spheres
Heretic/Hexen items
Crystal Vial	Crystal vial	crystal vial
Enchanted Shield	Enchanted shield	enchanted shield
Silver Shield	Silver shield	silver shield
Map Scroll	Map scroll	map scroll
Mystic Urn	Mystic urn	mystic urn
Quartz Flask	Quartz flask	quartz flask
Shadowsphere	Shadowsphere	shadowsphere
Torch	Torch	torch
Hexen weapons
Spiked Gauntlets	Spiked gauntlets	spiked gauntlets
Sapphire Wand	Sapphire wand	sapphire wand
Serpent Staff	Serpent staff	serpent staff
Firestorm	Firestorm	firestorm
Frost Shards	Frost shards	frost shards
Arc of death	Arc of Death	Arc of Death
Hexen items
Falcon Shield	Falcon shield	falcon shield
Mesh Armor	Mesh armor	mesh armor
Platinum Helm	Platinum helm	platinum helm
Dragonskin Bracers	Dragonskin bracers	dragonskin bracers
Clock Gear	Clock gear	clock gear
Emerald Planet	Emerald planet	emerald planet
Ruby Planet	Ruby planet	ruby planet
Sapphire Planet	Sapphire planet	sapphire planet

Hope I didn't miss any, feel free to augment. --Xymph (talk) 10:57, 20 December 2023 (CST)

Gauss was right, added two more. --Xymph (talk) 16:23, 20 December 2023 (CST)

← ← ←
I think we need to take a few final steps in this discussion: 1) names of parts of ultimate (4th) weapons in Hexen shouldn't be capitalized (for example: Quietus (Hilt) -> Quietus (hilt)); 2) all of the Hexen keys should be written lowercase in text (for example: Emerald Key -> emerald key); 3) caps in Hexen puzzle items - planets and gears all lowercase inside text (for example: Clock Gear (Steel in Bronze) -> clock gear (steel in bronze)), some IMO must be changed (Flame Mask -> flame mask, Yorick's Skull -> Yorick's skull, Glaive Seal -> glaive seal, Holy Relic -> holy relic), all others should be kept as they are; 4) for the sake of consistency I think that spike's subtypes should be written in lowercase in the things tables (i.e. Spike Down/Up -> Spike down/up). --Nockson (talk) 15:14, 28 December 2023 (CST)

I was already wondering when you'd bring these up. ;-)

1. Agreed.
2. Agreed. And while we're here, so should the Strife keys.
3. All puzzle items are unique, occurring once in the game. So all could be considered proper nouns. But indeed not the multiple gears and planets. So lowercase those but I'd prefer to keep all others unchanged, as they are the Codex, the Relic, the Seal, etc.
4. Sure.

Updated DMMPST thing tables per current proposal. --Xymph (talk) 07:24, 29 December 2023 (CST)

Thanks! I agree with your point on #3. Also, is there a possibility that the results of this discussion could become part of the Wiki's guidelines? So that new editors know how to write correctly. --Nockson (talk) 14:27, 29 December 2023 (CST)

Done. --Xymph (talk) 08:38, 1 January 2024 (CST)

← ← ←
It's a shame, but I missed one more thing that we need to discuss - Hexen classes - I assumed (by looking through existing pages) that they should be capitalized in text (example: "...for the Fighter it is...") and I've already fixed half of Hexen level pages this way before thinking that I need to ask this here. Should we keep it that way? My personal opinion is that classes should not be capitalized. I don't see anything special in these names. --Nockson (talk) 14:05, 12 January 2024 (CST)

It makes sense to capitalize the classes since they are part of a name - Baratus the Fighter. When you're using the classes by itself, you are still implying that name, just in a shortened form, instead of a generic class of "fighter". So in my opinion it therefore needs to be capitalized as well. --Gregor (talk) 16:35, 12 January 2024 (CST)

Works for me. --Xymph (talk) 03:19, 13 January 2024 (CST)

Forgot to answer here. I'm 100% agree and will continue with my caps fixing then. --Nockson (talk) 11:47, 17 January 2024 (CST)

Alias omission

Why are certain person aliases omitted on page names? Here's a few examples I've spotted so far.

Tom Mustaine > Tom Mustaine (ParadoX)
L.A. Sieben > Leo Sieben (Anavrin)
Jonathan El-Bizri > Jonathan El-Bizri (Biz)
Patrick Pineda > Patrick Pineda (Metacorp)
Jon Dowland > Jon Dowland (Teppic)

--Horizon (talk) 22:31, 21 December 2023 (CST)

No particular reason, I guess. Some articles exist since the wiki's earliest days, when conventions were not firmly established yet, others are recent. In some cases like Sieben, the person didn't use their alias much themselves and in commercial releases (Mustaine's too) it is customary to use only formal names, no aliases. I've made various adjustments. --Xymph (talk) 04:20, 22 December 2023 (CST)

There also might be very slight confusion between BiZ and Jonathan El-Bizri (Biz) with the auto-caps thing. - turn Biz into a disambig page and move BiZ to [[BiZ (mapper)]] to maintain consistent formatting like this? --Horizon (talk) 16:00, 22 December 2023 (CST)

BiZ is widely linked already, so that can remain the canonical link for that person. --Xymph (talk) 17:21, 22 December 2023 (CST)

Quite a few more are missing: (these are from skimming over random people pages)
Ola Björling > Ola Björling (ukiro) (this appears to be a redirect for some reason)
Malcolm Sailor > Malcolm Sailor (Hayduke)
Justin Fisher > Justin Fisher (Harlequin)
Charles Jacobi > Charles Jacobi (Chukker)
Jekyll Grim Payne > [[Jekyll Grim Payne (Agent_Ash)]]
Jim Lowell > Jim Lowell (Symbol)
Kim André Malde > Kim André Malde (Mutator)
Kyle McAwesome > [[Kyle McAwesome (kmc)]]

--Horizon (talk) 04:47, 27 December 2023 (CST)

Some pages renamed, for others who rarely/never used the alias themselves I added redirects. Pretty sure Jekyll Grim Payne is an alias, so it cannot use the "full name (alias)" format. Possibly McAwesome is an alias too, so I didn't rename that yet until some confirmation either way surfaces. --Xymph (talk) 07:04, 27 December 2023 (CST)

Sorry if it gets boring doing this, just trying to keep things somewhat consistent. ---Horizon (talk) 03:04, 28 December 2023 (CST)
Dan Townsend (sgt dopey) > Dan Townsend (Yukarin) - page was not moved with name update.
Jaakko Keränen > Jaakko Keränen (skyjake)
Elias Papavassilopoulos > Elias Papavassilopoulos (CaveMan)
David Asaad > David Asaad (A1s)

A few more...
Will Hackney (Archvile46) > Will Hackney (Kid Airbag) - page was not moved with name update.
Piotr Kapiszewski > [[Piotr Kapiszewski (Kapi)]] - would this even count as an alias?
Jan Van der Veken > Jan Van der Veken (BhadTrip)
Thomas van der Velden > Thomas van der Velden (Rabotik)

--Horizon (talk) 02:04, 5 January 2024 (CST)

Well, since there's a list, there's also:

Roland van der Velden > Roland van der Velden (space is green)
Malcolm Sailor > Malcolm Sailor (Hayduke)
Jonathan Rimmer > Jonathan Rimmer (JonR)
Kerkko Välilä > Kerkko Välilä (Robocat)
Nicklas Linnes > Nicklas Linnes (nathas)
Tom Mustaine > Tom Mustaine (ParadoX)
L.A. Sieben > Leo Sieben (Anavrin)
T. Elliot Cannon (Myscha the Sled Dog) > Thomas Elliot Cannon (Myscha the Sled Dog)
Jeremy Wagner > Jeremy Wagner (Iron Lich)

--Dynamo128 (talk) 05:21, 5 January 2024 (CST)

EDIT: I see that some of these have been brought up already, but for the sake of consistency I think it'd be better to rename them (L.A. Sieben seems particularly unfitting for the wiki standards as the first name tends to be used) rather than just having redirects - but that is, of course, only if the amount of work required to do that is reasonable. --Dynamo128 (talk) 05:23, 5 January 2024 (CST)

One more:
Paul Corfiatis > Paul Corfiatis (pcorf) (redirects for some reason)
Going from similar treatment just now to JonR. --Horizon (talk) 08:42, 5 January 2024 (CST)

As mentioned in my first reply, almost all Sieben's credits are by initials, so that seems the canonical styling for this person's name. That's why I kept it that way. Same for "T. Elliot", which is just a style convention to emphasize one's calling name as Elliot. Just like my middle initial P. isn't used much (or is public, even). I also commented on Mustaine already. As before, I don't feel it necessary to updating all uses of names with(out) aliases throughout the wiki into their new canonical paths. Redirects are not that harmful. --Xymph (talk) 09:42, 5 January 2024 (CST)

Hub categorization?

Last night Nockson and I briefly chatted about hub WADs w.r.t. the {{wad}} template, which reminded me of an entry on Ryan W's todo list. Currently single-hub WADs with a handful of maps are categorized as Multilevel WADs. Such mods exist not only for Hexen but also for Doom (II). Would it make sense to create a separate "Hub WADs" category for these? If Hexen's hubs are moved into a "Hexen hubs" category like Ryan proposed, the PWADs could go into that new category, both under the main Hubs one. Template type 'h' could auto-add the category. But is it meaningful to distinguish them from other multilevel WADs that way? And what to do about megawad hub-based mods, like Cabro's Legacy and the RAMP series? Should "Hub WADs" come in addition to the usual multilevel/episode/megawad types? Let's hear (uhm, read) your thoughts. --Xymph (talk) 06:49, 31 January 2024 (CST)

Well, if the major sorting factor now is the amount of levels then there's no need to add hubs into the template. Though I also think that the hub category is useful, it could be added manually. This hub question also touches the other thing that we discussed yesterday: partial and total conversions. After my 7 edits today, there are no pages on the DoomWiki that use the "t" or "p" parameter in the wad template, the categories for TCs or PCs in all of them were added manually. So the parameters for TCs and PCs are useless. So here are my proposals to change the wad template: either add an additional type2 field that can have parameters for hubs, TCs and PCs (dunno what to do with T/P conversions with hubs in them), or remove "t" and "p" parameters entirely from the template. --Nockson (talk) 12:03, 31 January 2024 (CST)

Removing the t & p parameters seems reasonable if they are no longer useful, although this request would perhaps be better put in the Template_talk:Wad page.
With regards to the "Hub WADs" cat, I would honestly favor a "Hub maps" category that can be added to the hub level articles themselves rather than associating this with the main page. After all, these are the actual hubs, not the PWAD overall. "Hub WADs" to me implies that the WAD is entirely (or mostly) made up of hubs, which isn't the case most of time - maybe a Hub WADs cat would make sense for these type of WADs specifically (if they exist). But the question is whether a WAD needs to be filed under a Hub cat just because it contains one or two hub maps. Sort of like creating an "Icon of Sin WADs" category, rather than just adding an "Icon of Sin maps" category to the maps that actually have one (that could be another worthwhile category to add btw :)). --Gregor (talk) 15:32, 2 February 2024 (CST)

That's a good proposal, it really will be nice and convenient to have "Hub levels" or "Hub maps" category instead of WADs. I support this! --Nockson (talk) 01:50, 4 February 2024 (CST)

Alright, category created, this search helps to find a bunch (but not all) of them. Also created the Hexen subcat per Ryan's todo.
Functionality in the Wad template should not be removed as it may be useful yet. After all, it is entirely feasible (albeit uncommon) to have TCs/PCs without levels, and we are already covering two such PCs.
What would be the use case for the "Icon of Sin maps" category? --Xymph (talk) 04:52, 7 February 2024 (CST)

Well, one would first have to define the Icon of Sin as the combination of Romero's head, monster spawner(s), and a boss texture plus some form of distorted voice sample being played at wakeup, so as to exclude such maps from the category that only feature one or two of these components, such as utilizing monster spawners or using Romero's head on its own. So HR MAP30 would fall under such a "IoS maps" category but HR MAP32 (uses monster spawners as a central threat) and HR MAP23 (uses Romero's head to simulate a reactor blowing up at the end) would not. I think it would be neat and useful for documenting purposes to have a comprehensive list of Icon of Sin maps, new and old, listed on one page.

Another thing to consider would be an even larger "Boss fight maps" or "Boss levels" category that the IoS maps category would be a subcat of. A boss level category would only cover maps that have some boss entity to fight or kill in it, so maps that use large encounters as a substitute for a boss, whether they occupy the final map slot or not, would not qualify in my opinion. Therefore, MAP24: Tough Skin River (BTSX-E1) or MAP30: Haunting Dreams (Scythe 2) do not count as a boss level while MAP30: Eternity (Eviternity) and MAP07: The Beating Heart (Heartland) very much do. But I'm sure there would be some fringe cases to discuss for either category. --Gregor (talk) 11:29, 7 February 2024 (CST)

Just as a follow-up on the idea of an Icon of Sin cat: I went ahead created Category:Icon of Sin levels. I am currently in the process of going through every map covered on the wiki that has a monster spawner in it to check if it falls under the IoS definition or not. I made the definition pretty broad, so as long as a map has a monster spawner and a boss brain together in a fight and the boss brain ends the level, preferably with some visual representation of an associated demonic entity (like the goat demon texture, or some evil reactor/machine, etc), it can be counted.

So for future article additions to the wiki this is something to consider adding under categories at the bottom of the page. And with that, I yield the floor. ;) --Gregor (talk) 05:10, 15 September 2024 (CDT)

Soundtracks

I've noticed a few weird things about the pages listed in the "Soundtracks" table seen here: {{Music}}

They are as follows:

• Doom music is missing E1M10: Sewers from the Xbox port.
• Doom II music is missing MAP33: Betray and all of the maps featured in No Rest for the Living.
• TNT: Evilution is listed under Bobby Prince, incorrectly implying he was the main composer (or deliberately contributed to the soundtrack at all). In reality, TNT's music was a collaboration between Jonathan El-Bizri, Josh Martel, L.A. Sieben, and Tom Mustaine, with some of Bobby's Doom II work re-used.
• The listing of soundtracks based on what composer was featured the most. While this works for games with single composers (i.e. Bobby Prince), this doesn't work for games with multiple composers like TNT: Evilution (see above) and Doom PSX (for which Club Doom was composed by Danny Lewis.

Another related complaint I have is that some games/campaigns do not have music pages of their own when I feel they should. These are

• Hacx
• Hell to Pay and Perdition's Gate
• The Ancient Gods, Parts one and two

MargaretThatcher (talk) 16:40, 5 February 2024 (CST)

Reference that template, don't transclude it, so this page doesn't get added to category Music.

• Xbox maps added.
• TNT Evilution split off and NRftL added (shouldn't be in the D2 table because assignments vary between releases).
• Soundtrack articles for Hacx, HtP and PG are meaningful only if there is sufficient reliable information about them, like track names, composer(s), lengths, etc.
• Doom Eternal soundtrack already mentions the DLCs should get dedicated soundtrack articles, with the same requirements.

--Xymph (talk) 16:42, 7 February 2024 (CST)

Would need to e-mail Jim Lynch about titles and better clarity/corrections on this, but for Hacx:

MAP01: Jim Lynch + Ellsworth Hall

MAP02: Jim Lynch

MAP03: Jim Lynch

MAP04: Jim Lynch

MAP05: Jim Lynch

MAP06: Jim Lynch

MAP07: Jim Lynch

MAP08: Jim Lynch

MAP09: Jim Lynch

MAP10: Jim Lynch + Ellsworth Hall

MAP11: Jim Lynch

MAP12: Jim Lynch + Ellsworth Hall + Mark Van Natta

MAP13: Jim Lynch + Ellsworth Hall

MAP14/Text screen: Jim Lynch + Ellsworth Hall

MAP15: Jim Lynch

MAP16: Ellsworth Hall

MAP17: Jim Lynch + Ellsworth Hall

MAP18: Jim Lynch + Ellsworth Hall

MAP19/MAP21: Jim Lynch

MAP20: Jim Lynch

MAP31: Jim Lynch

Intermission: not sure

Title: not sure

--Blursphere (talk) 17:48, 7 February 2024 (CST)

Coordination

Hello, I was wondering if the wiki has any kind of central coordination base, like a Discord server or the like. I couldn't find anything on the sidebar links but wanted to confirm since it's a pretty common arrangement these days. Thanks. —The preceding unsigned comment was added by Kisequé (talk • contribs) .

You just found it, right here. And for a quick chat, there is also Doomwiki (IRC channel), a few editors hang out there from time to time. --Xymph (talk) 03:02, 28 March 2024 (CDT)

I see. Very old-school, charming! I'm not terribly familiar with discussing over talk pages so I apologize as I get used to the conventions.
On the IRC chat, I did see that but was unable to connect. Are there any common errors in getting set up there? I've never used the technology before. Kisequé (talk) 13:46, 28 March 2024 (CDT)

For talk pages, you can learn from examples all around the wiki, but your first reply is fine. :) For IRC, one client used by several editors that is pretty easy to set up and use, is HexChat. --Xymph (talk) 14:30, 28 March 2024 (CDT)

Long map names

Some of the recent WADs added to the wiki have very long map names. They break columns on the WAD pages and (IMHO) look bad on mappers' pages. This is especially important if we will create pages for such maps. You can check HERE for some context. Let's discuss how to handle such cases. For the sake of readability and consistency I propose to add the following phrase to the guidelinse: Level names longer than 40 characters must be truncated using an ellipsis. This shortened form of the level name should be used everywhere, including in the title of the article about the level. The only exception is the preamble of the article about the level; the full name must be written there. --Nockson (talk) 11:49, 24 May 2024 (CDT)

(Waited for other first responders, then forgot about it myself.) With this topic popping up again via RAMP 2024 MAP137, I agree we need a practical limit. Besides column layout, long names also affect layout of the title area on the pertaining pages (at least in our default Monaco skin; haven't checked others), and navbox layout. I am less concerned about entries in the Body of Work on a mapper's article; if they chose a ridiculously (IMO) long and repetitious name, that reflects on them, not the wiki - which just provides a factual listing there.

For article titles and map listings in columns/navboxes, MOS:AT and WP:CRITERIA provide useful input: a title should be sufficiently precise (to distinguish it from similar subjects) but also concise (no longer than necessary to identify it), with the goal being "to balance brevity with sufficient information to identify the topic". Since the map name is the title of a work, I think we don't need to truncate more than necessary to achieve a reasonable layout in the places where it matters – although Wikipedia has examples of much firmer abbreviation. Thus I think a limit of 40 characters is way too small; we already have 115 map articles with names of 40 characters or more (excluding slot and parenthesized WAD). The current top-10 of longest names in my .ini collection consists of:

Slot	Name	WAD	Name length
MAP27	Taciturn it waterway, and an bearable buttonhole inadmissible it diplomatically: of and contest expiration date enact to inoffensive woLf	WOOO 2	137
MAP08	A Roboticized Lizard Comprised Entirely of Moving Wooden Parts, Neurokinetic Circuitry, and the Heart of a Moldy Bald Eagle	32in24-12	123
MAP217	An E4M1 PSA: To spread awareness about an over abundance of E4M1 maps - lets work together to find a cure	Rabbit's All-comers Mapping Project 2023	105
MAP27	stop me if you've heard this one. a marine walks into an infected space station (crowd starts chuckling)	Doomworld Maximum Project 2022	104
MAP16	Why Is Bethesda Still Selling Final Doom for $4.99 On Steam When It Comes Free with DOOM & DOOM II Now	TNT: Threevilution	100
MAP111	Green Rolling Hills with Lots of Nice Rabbit Girls But Secretly It Is Still Hell	Rabbit's All-comers Mapping Project 2023	80
MAP212	The Misadventures of Carl the Friendly Arch-vile and His Army of Friendly Demons	Rabbit's All-comers Mapping Project 2023	80
MAP29	A Fairly Simple Tech Base With a Minor Demon Infestation and a Few Leakey Pipes	Rabbit's All-comers Mapping Project 2022	79
MAP07	Weed's like, uhh, capitalist conspiracy to keep us down, man... *hits blunt*	DBP45: Vrack Botanicals	76
MAP13	You're Not The Kind That Needs To Tell Me About The Birds And The Bees	512 Linedefs of /vr/	70

So a limit of "around 100" characters seems reasonable, with the top-2 remaining outliers that won't be changed anymore. But a ridiculously (IMO) repetitive name should be truncated much more, like MAP92 was curtailed in Junkfood 3's column listing and MAP137 in RAMP2024's. Thoughts, anyone?

Lastly, for now, I remembered the somewhat obscure HTML element <wbr>, which fortunately is supported in MediaWiki, and can be used to make the very long nonsense "word" in DBP62 still wrap nicely in varying window/screen widths. Since the overall length of that name is 93 characters, this trick makes it acceptable within the proposed guideline. --Xymph (talk) 05:48, 13 August 2024 (CDT)

I think 100 characters is a reasonable limit. Looking at the list Xymph provided, most map names that approach this limit tend to be...not particularly serious. Gauss (talk) 07:58, 13 August 2024 (CDT)

Sounds like a plan. I wanted to comment on this yesterday but didn't get around to it. I do agree with most of what Xymph said. I also thought the proposed 40 character limit was a bit too stingy, given that just thinking about something like BTSX, there are already several map names in there that extend beyond that limit. On the other hand, 100 characters is probably a lot more than what is needed for any sensible name (70 or 80 characters already look terrible on the page), even where a longer map name is justified for artistic reasons and the author isn't just taking the piss.

In my opinion, the limit should be somewhere around 60 characters (between 50-70), with the rest replaced by an ellipsis, and the full map name displayed in a footnote after the truncated name at the beginning of the map article, just like in the example cited by Xymph above. For WAD articles without map articles, a footnote can be used in the level listing as well. That way we can set the overall character limit to something more reasonable in the middle of the park and get the best of both worlds: cleaner listings and article names as well as accurate coverage. --Gregor (talk) 08:51, 13 August 2024 (CDT)

I'll just say here that IMO if a title is long enough to deserve a cut, then the cut shouldn't be just at the character limit. It should be at the first place where it can make sense to cut. For example in the table above, the first title could be cut to just "Taciturn it waterway", the second could be just "A Roboticized Lizard", the third could be just "An E4M1 PSA", the fourth "stop me if you've heard this one", the fifth "Why Is Bethesda Still Selling Final Doom", etc. As long as there's going to be a note that the title was cut short, let's actually cut it short. --Gez (talk) 09:59, 13 August 2024 (CDT)

Good point. Again, I think the full title should be included in a footnote to avoid accusations of displaying erroneous information. And by making use of footnotes we do not need to go to the upper limit of what is still barely tolerable in terms of character limit. --Gregor (talk) 10:36, 13 August 2024 (CDT)

I agree with both of you. I think that when the map name surpasses the character limit it should be a trigger for us to cut that name, not the length at which we need to stop when cutting. --Nockson (talk) 14:28, 13 August 2024 (CDT)

Hmm, now I almost regret including the extreme WP truncation as example, as I don't like truncation to be that... extreme. With this approach, if the limit is put at, say, 60 characters, then a name going over it just a bit gets trimmed down to a few words, e.g. Dictes Moy Où, N'en Quel Pays est Sérana, la Belle Doomeuse (61 chars) to "Dictes Moy Où..." and Vortale forgot to make a shitpost and instead made an actual map (64) to "Vortale forgot to make a shitpost..." or even "Vortale forgot...". But a name staying just under the limit would remain unscathed, e.g. Bricks, yes bricks this time, lots of bricks (brown bricks) (59) and I've Got Two Words for You and They're Not "Happy Birthday" (59). In all cases the mapper chose the name for their own good or unfathomable reasons, yet they're treated very differently if this guideline would be adopted. That feels arbitrary (because the limit of 60 is in itself somewhat arbitrary, even if settled on here by consensus) and unfair. Also, choosing the number of words down to which a name gets truncated becomes subjective, in the examples by Gez it varies from 3 to 7 (why not "stop me if..." for the fourth example?).

I feel the simple rule "your map name gets truncated to XX characters if it (notably) exceeds it" suffices to meet our practical layout needs without passing judgment on how much of the name "makes sense", and is thus more fair and objective, and more easily applied to past and future cases.

As for the actual XX value, we have 36 articles with names of 51 or more, and 15 of those are longer than 60. It is entirely feasible to update those 15 if the limit were put around 60 (it makes no sense to truncate that French name by 1 character), and the example names I gave look alright in their article titles and their WADs' Levels columns. But if a majority wants the limit around 50 characters, that would okay too – but induce more work that I won't carry out alone (just saying...). I can however not support Gez's proposal. --Xymph (talk) 07:40, 14 August 2024 (CDT)

This proposal brought up by Xymph seems to be what's most reasonable to me, so I'd say personally that's what I'd like to see implemented. --Dynamo128 (talk) 14:22, 21 August 2024 (CDT)

← ← ←
I am submitting for discussion a preliminary version of the rule, adjusted based on the results of the discussion above. It should be added to the Article format section of our Policies and guidelines.

Level names longer than about 60 characters must be truncated using an ellipsis. This shortened form of the level name should be used as the title of the article about it, in the list of levels on the WAD overview page and in the navbox template. The full name of the level should be used in the preamble of the article about it, in the body of works on the mapper's page, and may be additionally indicated in a note to the list of levels on the WAD overview page.

Please share your thoughts! --Nockson (talk) 12:45, 13 September 2024 (CDT)

Yup, that's what I had in mind too, apart from one additional word: "longer than about 60 characters". It makes no sense to truncate a 62-character name, or to cut off in the middle of a word, and when a 10-character word starts at position 58, it can be truncated before that word. Basically, let's be pragmatic about where to truncate. --Xymph (talk) 15:24, 13 September 2024 (CDT)

I was thinking about that too, but forgot to add, sorry! (added it) I was also thinking about adding something about using <wbr> to cut long words in the level name. What's your opinion on that? Should it be a part of the rule too? --Nockson (talk) 15:33, 13 September 2024 (CDT)

Nah, that doesn't need to be in a guideline. It's just a practical trick when a ridiculously long letter-salad would break column/table/page layout. --Xymph (talk) 16:05, 13 September 2024 (CDT)

Merging articles

I have noticed two pairs of articles that I believe should be merged:

• Some Doom II-specific projectiles triggering linedefs and Projectiles triggering linedefs
• Indie games and Fan-made Doom games

These articles have overlap to the point where I think, for each pair, one article should be deleted and the other should have missing content transferred. This would break some links, so I'm wondering what the usual approach is. Should some speedy edits be made to transfer content and change links before marking for deletion? -Inuk (talk) 09:03, 31 May 2024 (CDT)

It's advisable to add {{Merge}} to the pertaining pages and post proposals on their Talk pages (like you already did for one), to invite discussion and ideas how to combine the content. Hasty edits are usually not a good idea in this area. Unfortunately we seem to be in a quiet period for activity by editors, let alone admins, so this could take a while... some of the merge category entries are lingering there for years. --Xymph (talk) 10:53, 31 May 2024 (CDT)

While the first pair seems to indeed be about the same thing; the second pair isn't. Fan-made Doom games is about unofficial Doom games, such as DRL or MiniDoom; indie games is about non-Doom games made with Doom ports, such as Hedon or Selaco. The only overlap is the "Non-Doom games using the Doom engine" section from Fan-made Doom games, section which honestly could be removed as it directly contradicts the page's title. --Gez (talk) 06:41, 2 June 2024 (CDT)

Praetor Suit Upgrades

In the praetor suit page, I was wondering if it would be fine for me to add the tables from the Praetor suit points page with the upgrades to the upgrades section, or if I should create a subpage so that it doesn't make the page massive and long. Robotcthulhu (talk) 11:53, 3 September 2024 (CDT)

If you're asking if you should duplicate that information to another page I would say no; just link to the existing page for it. --Quasar (talk) 10:20, 13 September 2024 (CDT)

HotCat extension

Is there a chance we could get the HotCat extension enabled on this wiki?

It would make it a lot easier for editors to add or remove categories. --Ixfd64 (talk) 11:11, 9 September 2024 (CDT)

Adding other doom games to item page descriptions

Items and enemies have appearance statistics in their pages, detailing when is their first appearance and how many times they appear throughout various classic doom games. However, those appearance stats only cover the 4 episodes of Doom 1, Doom 2, Final Doom, and Doom 64 + TLL. Given the fact that in the Doom + Doom II port Master levels, NRFTL, SIGIL, and LoR are considered official games equal to those mentioned in the last sentence, shouldn't they be covered too? ONETAPPYBOI (talk) 11:15, 12 September 2024 (CDT)

That would be quite a bit of information for just an appearance statistics section, which is already medium length-ish. Maybe create a subpage titled "(whatever thing)/Additional appearance statistics"? Robotcthulhu (talk) 05:19, 13 September 2024 (CDT)

Those stats were generated by DMMPST for the IWADs only, like the intro sentences state. They are already fairly trivial in nature. To expand them with PWAD episodes really goes into piffling detail, IMO, and I have no intention of updating DMMPST for that. Subpages would also be overkill, IMHO. --Xymph (talk) 05:39, 13 September 2024 (CDT)

Personally, I wouldn't mind having them, since after all I did make them manually for the LOR things, but it's not important. I agree a subpage would be overkill; if anything it's a show/hide toggle that should be used when faced with a surfeit of trivial details, cf. the big table of line types. --Gez (talk) 17:00, 17 September 2024 (CDT)

NaNoWADMo WADs

I noticed from the NaNoWADMo doomworld post that the released projects don't align with this page. Just skimming very quickly they seem to be "notable" such as Doomed: By the Hour 2 by Finnks13 & Yumheart or Vortale's The Quinary Conundrum. I also saw a past discussion about a speedmapping series and the issues with adding "blank" links creating a lot more work for you guys. The speedmapping series seems to have individual links to each map now so I'm unsure if this has been resolved over time.

I was planning to add the names of each finished project, include the link to the author (if the page exists already), and then include idgames/doomworld forum post. I'm also not sure if you truly want everything finished/released or just things deemed notable.

Sorry for all the edits, was figuring out links and will use preview next time. —Preceding unsigned comment added by 2607:FEA8:12E2:3A00:29C3:7CB8:42B1:9341 (talk)

I'm not familiar with the project series and the choices made to list or not list some entries. It seems to me that everything that has a stable release can be listed under the annual summaries, but redlinks should not be added unless a mapset is considered notable and reasonable likely to get wiki coverage. Individual maps in {{speedmapping series}} should not be redlinked as they are generally considered too trifle to invest editor effort into covering them, but exceptions like the 32in24 series do exist. Assessments can change over time, as does the time I have available for bot-account actions (which is less than a few years ago). E.g. after some internal discussion it was decided to cover all maps in the JoM series after all, but nowadays something like that is unlikely to happen again. --Xymph (talk) 05:50, 17 September 2024 (CDT)

Map labels

UMAPINFO allows to define the map label. Typically in this wiki we have used the map slot as a label (e.g. E1M1: Hangar, MAP01: Entryway), except for Hexen which doesn't show map labels and where it was instead decided to use a hub-based approach (e.g. Hub 1: Winnowing Hall). The issue arises in things like Legacy of Rust, where you have MAP01: Scar Gate showing up as E1M1: Scar Gate in-game, and likewise MAP08: Second Coming showing up as E2M1: Second Coming. How should we reflect this in the existing and future articles? --Gez (talk) 05:22, 21 September 2024 (CDT)

I don't think it matters that much what is displayed in game. After all, Doom II displays "Level" as the label before the map name on the automap but we refer to it as "MAP01: Hangar" regardless. That's just the generic identifier for all Doom II map slots independent of what is displayed on the automap. Some maps don't display any label before the name but they are still identified as "MAP01: %%" on the wiki anyways.

The ugly compromise would be to do what we did with Knee-Deep in Knee-Deep in ZDoom, where the slots are printed with the MAP label followed by their displayed in-game label→ "MAP01: Z1M1: Hangar". But that was an exception to the rule because it was a demake of a ZDoom mod, and I don't think we want to go down that rabbit hole. Of course ports that support MAPINFO allow modders to define their own slot identifiers that can't be accessed through idclev##, and these labels are then also used in the wiki articles. So maybe that's a decent definition: if a map can be accessed through the idclev cheat, it gets the map label. LoR would still count because the idclev cheat works just fine when played in ports like DSDA-Doom. --Gregor (talk) 08:59, 21 September 2024 (CDT)

In KDiKDiZD's case, the Z1M#: thing is actually part of the map title. It's not using the "label" value, in fact it's using "label = clear" to hide labels in-game. --Gez (talk) 11:43, 21 September 2024 (CDT)

Right but on the wiki page it nonetheless creates the effect of two perceived labels printed back to back, even if the second one is part of the map name. In the end, it's a hack to achieve the same effect as if a custom label were displayed. So in my opinion, the intent is the same as if UMAPINFO was used, that is to say, the Z#M# label is not really part of the map name, because it is not perceived in game by the player as part of the name either, but as the map label instead. So I would prefer to use either one (MAP01: Hangar) or the other (Z1M1: Hangar). But again, KDiKDiZD is an edge case and an exception to the rule, being a vanilla demake of a ZDoom mod. --Gregor (talk) 12:06, 21 September 2024 (CDT)

Articles on Notable Wads for being Racist

I was wondering if it would be appropriate to allow articles on these kinds of wads if they have a certain amount of popularity on the internet or are they not allowed because it's not a good idea to give them more attention? Justice ∞ (talk) 01:13, 26 September 2024 (CDT)

The wiki is a community wiki; those things may be notable outside of the community, but they're not within. There are so many better topics that could be covered... It's not like our wanted pages count is getting dangerously low. --Gez (talk) 01:46, 26 September 2024 (CDT)

Edits to DOOM.WAD and DOOM2.WAD stuck in pending limbo for two weeks

I've recently been searching around for official revisions of Doom and Doom 2 whose IWADs haven't been added to DOOM.WAD and DOOM2.WAD yet and found two revisions of those WADs in the Doom I Enhanced and Doom II Enhanced releases of the game that weren't on their respective pages, so I decided to add them. I've done this before, and last time it was approved fairly quickly IIRC. This time, however, it has been two weeks with no review. Is there anything I can do here? —The preceding unsigned comment was added by Arctic Circle System (talk • contribs) .

Two weeks is nothing, some edits remain pending for months. There are few editors who consistently check every edit and accept most of them, but some edits require more knowledge (and sometimes effort to clean up), so they stay on that list until an admin handles them. That unfortunately can take a long time due to work, real life, lack of energy, and what have you.

As for your edits, I accepted some if they looked plausible and correct, like the PC-98 doom2.wad. But while I found D1/D2 entries on gogdb.org, they are by a "test developer/publisher" (which makes no sense for the wiki), and there are no D1/D2 "Enhanced" products on the actual GoG site. So what are they? Are they real products that should get a wiki article (otherwise they shouldn't be redlinked)? And where did you get the .wad files? Too many uncertainties to accept the edits. I was hoping Gez could look into them, being someone who seems to follow the various game stores closely, but that hasn't happened yet. So here we are today. --Xymph (talk) 06:19, 2 October 2024 (CDT)

According to GOGDB, they were included in the following two packages which were developed by id and published by Bethesda: DOOM (1993) and DOOM II. Hopefully this should be enough to prove their authenticity. You can also find the MD5b hashes of each IWAD in a metadata file on GOGDB. DOOM I Enhanced DOOM II Enhanced.Arctic Circle System (talk) 13:15, 3 October 2024 (CDT)

The "Doom Enhanced" entries on GOG are just the Doom Classic Unity port package, which while discontinued is still available. As listed on the GOG.com page. I'm not sure they need articles so I don't see a need for the redlinks; I suppose they could be redirects. --Gez (talk) 14:38, 3 October 2024 (CDT)

Thank you, Gez. I listed them separately because the hashes listed for the Doom Classic Unity ports on those pages were different from the ones I had, presumably they had console-related changes, and forgotten about the connection. Arctic Circle System (talk) 16:22, 3 October 2024 (CDT)

Crediting Box Doom on mapper pages

I'm wondering, what would be a good procedure for crediting (Box Doom), which just hit RC1? It's in a bit of a weird situation compared to other Quilt-like wads, as there's numerous maps, however most of Box Doom is in MAP02 with a few other things like an opening, credits and secret map around it. Should it be credited like MAYhem 2024 where I list MAP02 as a standard collaboration between 40 odd mappers, or should it be credited like Tribute Quilt where I say who made what segment specifically? (The map's individual segments are named.) What do you guys think? --NiGHTS108 (talk) 10:51, 3 October 2024 (CDT)

Well, it is indeed different from Tribute Quilt where the maps are nicely laid out on a grid. While the boxes are numbered, I'm not sure how much that actually helps with identifying a particular contribution for player since level progression isn't 100% linear as far as I can see. But even it is, who wants to count through dozens of boxes to find the one they're looking for? So it's kinda useless or at least very cumbersome for finding a specific map. Then again, dumping 40 other mappers behind the credit for one map segment is also a pretty ugly solution. So I would default to using the provided credits from the DW release post and credit each mapper with the specific box(es) they made. --Gregor (talk) 22:48, 3 October 2024 (CDT)

Alright, I'll take your word for it then. --NiGHTS108 (talk) 11:10, 4 October 2024 (CDT)

Using ChatGPT to grammar check large pages and improve sections

I am going to start experimenting with using OpenAI's free version of ChatGPT to improve grammar and flow of certain article pages. I will not submit these edits for review, rather, I will create subpages for my user page where we can review them and determine whether they should be published. Is anyone against this or has any comments on this? PS I was inspired by Xymph and XymphBot. --Robotcthulhu (talk) 08:24, 8 October 2024 (CDT)

ChatGPT's prose is very recognizable and, IMO, a big turnoff. When I recognize a text as written by ChatGPT, I just can't finish reading it. If a person didn't bother writing it, why should I bother reading it? So for this reason, I don't see a point in turning our existing articles into AI slop; it won't improve the writing. --Gez (talk) 09:00, 8 October 2024 (CDT)

I am opposed to any use of AI here; this is unnecessary. I was the academic meet English writing and grammar expert for my high school, as well as recipient of a perfect score for the English portion of the ACT. Finally, I also achieved a 99.8% score (because it was the maximum allowed) on my Freshman Comp I final paper in college, with a recommendation to CLEP out of Comp II. I have sufficient skills to ensure that any wiki content I touch is readable. --Quasar (talk) 10:16, 8 October 2024 (CDT)

I agree with Gez and Quasar. I'm not opposed to AI in general - it does have good applications and potential - but writing our articles is not one of them. It certainly isn't going to help me write walkthroughs, as this task simply can't be automated. Plus, it opens this wiki up to criticism from the "AI bad" crowd; it's just too controversial a subject. Gauss (talk) 10:18, 8 October 2024 (CDT)

Adding on to this, Wikis should be a source for precise and concise information. The AI cannot delve into more detail on a subject, it can only pad out the input text with fluff, which runs counter to what you expect from a Wiki. You also cannot guarantee it's not slipping in hallucinated details that may go undetected in a mass-edit. The risk of introducing misinformation and the general fatigue that comes from trudging through text you *know* is just there to take up space would make this a net negative to the article. There are other grammatical/spellchecking tools that do not involve rewriting the entire article, and I feel a sweep from those would receive a warmer welcome, as long as there is still human supervision. Billa (talk) 11:40, 8 October 2024 (CDT)

We're all doing this as a hobby, because we enjoy writing and contributing to articles. Why would we want to use AI to replace us? Even if AI could handle all tasks of writing articles, it would not be desired by most of us. Sure, XymphBot handles a lot of the heavy lifting around here when it comes to article creation, but what is delegated to scripting are just the menial tasks that nobody really wants to do by hand anyways. Writing articles or article sections on the other hand is a creative work. That's not something we want to hand over to scripts or AI since it's where most of the fun of contributing to a wiki comes from.

In a few years AI might very well be unavoidable for the Doom Wiki, as it becomes completely indistinguishable from the real thing and is used by editors and anonymous contributors all the time. At that point, one could probably just hand over the entire wiki to an AI, which could automatically generate well-written articles for any and all WAD releases on DW with zero human input (welp). So we might very well be fighting a losing battle here, but let's not bring about this dystopia any earlier than absolutely necessary. --Gregor (talk) 13:01, 8 October 2024 (CDT)

I understand all of your points. I just thought it would be an interesting experiment, that's all. I'll stop. Robotcthulhu (talk) 19:36, 8 October 2024 (CDT)

Killing Time

Given it's now open knowledge that Killing Time is a Doom engine game, what are opinions on how we should cover it? As a 1995 pre-source-release commercial title it is technically privileged to the same treatment as Heretic, Hexen, and Strife if we are to go by existing precedents. I suppose starting with an article for the original game itself, and one for the remaster, is a no-brainer and then whatever people feel inspired to cover from there is a separate thing. --Quasar (talk) 01:27, 19 October 2024 (CDT)

I think that sounds good. Robotcthulhu (talk) 05:25, 19 October 2024 (CDT)

Works for me. Had no idea about the Doom engine in the original. --Xymph (talk) 05:49, 19 October 2024 (CDT)

Ancient Gods Parts 1 & 2 Soundtrack Article

I worked on a soundtrack article for The Ancient Gods parts 1 & 2, and the table is finished. All it needs is some people to put more info in. If anyone wants to add stuff, feel free!
User:Robotcthulhu/Ancient Gods Parts 1 & 2 Soundtrack
All the track info is from the Spotify playlist. --Robotcthulhu (talk) 09:28, 23 October 2024 (CDT)

This does not appear to be any sort of official stream; how are we to know that any of this title information is accurate? As far as I have been made aware no such listing has ever been published by the song writers but correct me if I am wrong. --Quasar (talk) 23:40, 17 November 2024 (CST)

The playlist is under the artists Spotify pages, and they are both verified, so I'm pretty sure this is the official soundtrack. --Robotcthulhu (talk) 05:16, 18 November 2024 (CST)

"Ben" has no apparent relation to Andrew Hulshult or David Levy. When making such an assertion, please back it up with link(s). --Xymph (talk) 06:02, 18 November 2024 (CST)

Proposed CSS mod and template for keyboard keys

Hello world! Long time editor, first time CPer. I'd like to propose the site CSS be modified to incorporate the .keyboard-key class from Wikipedia's Key press template. Further, I'd like to propose the {{kbd}} template I just created be accepted for use on the wiki generally. An example of the usage of this template can be seen in an edit I just made at Straferunning. (The current template in-lines the CSS for proof-of-concept purposes.) Please let me know if there is anything I can do to improve any part of this.

P.S.: Example usage/appearance: Shift+↑+Alt+→

-- DragonHawk (talk) 13:41, 25 October 2024 (CDT)

Looks nice and useful, but ultimately this is up to an admin. --Xymph (talk) 10:52, 26 October 2024 (CDT)

More ways to document maps with completion issues

I want to document completion issues in maps (cannot go up to 100% in kills, items, or secrets) in a more systematic way, making it possible to have a complete overview of when this is covered in the wiki. Basically a list article of maps with completion issues (and maybe category pages for completion issues). It would take a large amount of data accumulation to create a useful listing of this type, but it would indeed be useful eventually; when reading about bugs in articles, I have discovered new workarounds using my technical knowledge, essentially solving them as though they were puzzles, and collecting current information into a single listing article would also invite others to apply their knowledge to unsolved completion issues. Supposing these were put into subcategories, it would be interesting to see which mapping decisions cause the most completion errors. I have only a short list of maps (all eligible maps from the IWADS + ~10 megawads) to put in such an article, so it would initially be a bit bare-bones, but I think that is fine. My current plan is that I make this article soon no matter how much content I have for it. I would like your thoughts on all of this first however—is it fair of me to use Doom Wiki to essentially make a puzzle hit list? -Inuk (talk) 07:39, 17 November 2024 (CST)

Not sure what you mean by that last sentence. If something is relevant information about already covered maps and is combined in a meaningful way in a new list, then it is a valuable addition to the wiki, IMO. In fact, it's better to start small(ish) – e.g. just the IWADs – and gradually expand, because saving it up until a massive info dump makes it harder to digest and review by other editors. The details about each completion issue should of course remain in the pertaining articles only, the list then serves as a summary/overview. --Xymph (talk) 08:25, 17 November 2024 (CST)

I can see the purpose in a category that lists maps which cannot be 100%ed, but I don't quite get the whole "solving puzzles" aspect you're implying. Do you mean "solving" as in directions of how to complete the maps in-game using speedrunning techniques? What actually causes the bug is not really ever any mystery since you can just open the map in an editor and find the offending linedef or sector. I also don't see how most of these could be "solved" anyways when there's a line action missing or monsters are stuck in out-of-bounds closets. You can document these as bugs but not really fix them without editing the map. What exactly are you trying to achieve with this list besides documenting bugs?

Maybe create this article first in a sandbox on your user page, so we all have a better idea what exactly you have in mind before moving it into main space. --Gregor (talk) 10:01, 17 November 2024 (CST)

What I mean by puzzle-solving, and the hit list for unsolved puzzles, is my agenda: I like to 100% stuff (especially for speedrunning, which on a competitive level must take place on the original versions of maps), and I like workarounds that allow you to get 100%, but they of course need to be discovered. Hence, this article proposal. The maps being bugged is part of the challenge and what makes it interesting. Sure a lot of cases are likely totally unsolvable, but I would never rule them out completely as is often done in these map articles. For example, you mention action linedefs missing—here is a map with precisely that bug, and you can use a zero press to obtain the secret. The person who originally added the bug stated it was impossible to obtain. You underestimate how bugged this game is—a monster stuck in a monster closet is not an automatic write-off either, because if you glitch out of bounds and shoot projectiles at the closet, the projectiles clip slightly through before exploding, potentially dealing direct hit damage through a solid wall (here and here for useful instances of this). And that is just what I know. Good pointer regarding the sandbox, I will try that out before making the article proper.

In summary, I like to 100% stuff, but not all stuff is 100%able as intended, or intended to be 100%ed, but sometimes it has been proven to be 100%able in spite of this. Therefore I want to make this article which gives an overview of completion exceptions and (briefly, maybe a 1-letter category of) how each is currently understood. Naturally, others can derive their own uses out of the article, but I have my own motivations. -Inuk (talk) 12:01, 17 November 2024 (CST)

Screenshots for Doom II

The following maps for Doom II don't have screenshots/don't have enough screenshots:

• MAP09: The Pit
• MAP11: Circle of Death
• MAP12: The Factory
• MAP13: Downtown
• MAP14: The Inmost Dens
• MAP15: Industrial Zone
• MAP16: Suburbs
• MAP18: The Courtyard
• MAP19: The Citadel
• MAP20: Gotcha! might have enough...
• MAP21: Nirvana
• MAP22: The Catacombs
• MAP23: Barrels o' Fun might have enough...
• MAP25: Bloodfalls
• MAP26: The Abandoned Mines

List is WIP

I can get screenshots for all of these maps. How many screenshots should I get and what should I get them of? --Robotcthulhu (talk) 08:55, 21 November 2024 (CST)

I was taking care of these, but due to lack of time I haven't been able to progress past MAP06. If you intend to take over this project, then please use the same convention I've used for Doom 1 and Doom 2 up to MAP06, that is: 640x480 screenshots, no HUD, no gamma correction, no crosshair, and visible landmarks of the map that can be tied to the walkthrough. I used ZDoom and occasionally DSDA-Doom to ensure the screenshots would look accurate. If you cannot manage to achieve this accuracy, then that means the screenshots would have to be replaced in time (such as the ones in Gotcha, which are not acceptable), so it's best not to bother at all until I have more time to finish them up. Just my two cents. --Dynamo128 (talk) 09:00, 21 November 2024 (CST)

Thanks! I plan to use wadCMD, which uses no freelook and no crosshair, normal status bar. --Robotcthulhu (talk) 09:14, 21 November 2024 (CST)

In that case, that would, as stated, be directly against what is by now the majority of screenshots on the wiki: please do not use any HUD or status bar, as shown in the screenshots taken on MAP01: Entryway, that ought to be the template to follow for greater consistency. --Dynamo128 (talk) 09:26, 21 November 2024 (CST)

We don't have a page on wadCMD, so I had to search for what it is, and found WAD Commander at https://wadcmd.com/ . Using a browser version instead of a regular port raises (my eyebrows and) the question: does this produce equivalent results in the specified resolution, compared to the ports Dynamo uses? Maybe you can post a sample shot? --Xymph (talk) 09:36, 21 November 2024 (CST)

Here's the test shot (The opening room of Entryway, using my BFG Edition Wads with the patched medkits. I have more if you want more examples. --Robotcthulhu (talk) 08:48, 22 November 2024 (CST)

Sorry, but that looks bad compared to this, possibly because it doesn't even meet the main requirement of 640x480 resolution. Also, the shots of vanilla levels need to use the original vanilla IWADs ("resembling vanilla Doom as closely as possible"). Thank you for mentioning that you're not using that, as that isn't clear from this particular scene. --Xymph (talk) 10:03, 22 November 2024 (CST)

I thought I could help with getting the screenshots, Dynamo128, but I apparently can't :(. Also, I noticed that there isn't a category for stock levels needing screenshots. One more question: If I took the average of all the statistics for each game's stock levels from the list of stock level statistics page and put them under each header, would that be OK? --Robotcthulhu (talk) 10:12, 22 November 2024 (CST)

No problem, your help in other areas like the modern titles is more valuable IMO. Dynamo can resume his project when he has spare time again, and for the wiki it is important that screenshot series for a given WAD are as consistent as possible.

The ScreenshotsNeeded template already adds the appropriate category, no other needed.

That stats list resulted from what used to be a redlink here, and most of the data is already in each map page. The remainder, and the list as a whole, is just a gimmick anyway, and doesn't need to be copied elsewhere. --Xymph (talk) 10:35, 22 November 2024 (CST)

Mapper stubs

What exactly constitutes a mapper's page not being a stub anyway? Just curious since my own page and all the ones I have made are marked with stubs, though others aren't, basically I'm just asking is there any non-private information I can add to a mapper's page to un-stub it? Thanks! --NiGHTS108 (talk) 15:52, 12 December 2024 (CST)

The lede should be more informative and elaborate about their accomplishments than just the basic (and often boiler-plate) intro sentence or two. --Xymph (talk) 16:08, 12 December 2024 (CST)

Thoughts on covering map WADs

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

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

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

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

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

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

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

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

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

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

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

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

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

Some of my comments/thoughts:

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

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

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

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

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

Regarding "self-promotion", I believe that:

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

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

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

Bot message for new users

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

Dear (user's name),

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

(insert list here)

Thank you, and have fun,

(bot signature)

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

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

---

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

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

A couple of tips upfront:

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

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

---

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

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

---

If you want to help out, you could:

Write walkthroughs for maps that need them.

Add music tracks to WADs that need them.

---

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

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

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

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

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

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

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

I'd suggest this tweak:

---

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

---

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

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

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

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

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

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

Map stubs category keeps growing

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

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

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

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

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

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

Code syntax highlighting

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

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

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

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

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

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

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

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

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

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

Styling of key actions in articles

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

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

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

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

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

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

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

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

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

"Pacifist Paradise" page

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

Mappers with map pages without pages for themselves

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

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

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

Credits map notation within WAD pages

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

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

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

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

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

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

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

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

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

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

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

Anti-consumer practices

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

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

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

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

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

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

Doom TDA weapon splits

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

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

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

Adding in-universe timeline?

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