Template talk:Wad

Author cat bug

I've used "|authors=Various" instead of "|author=some name" many times already, and that doesn't result in the bug occurring now on ZDCMP1, which displays [[Category:{{{author}}} levels]] at the top of the page. Anyone know how to get rid of it?

{{{author}}} will be worth {{{author}}} if author isn't set -- and that's not an empty string, so #if: will be true. On the other hand, {{{author|defaultvalue}}} will be worth defaultvalue is author isn't set. Therefore, {{{author|}}} will be worth an empty string is author isn't set, and the #if: will be false, as intended. --Gez (talk) 09:48, 30 March 2017 (CDT)

Indeed, but now a single existing author does not get his levels category added, as intended: e.g. Earth (WAD) and Going Down. Further puzzling ensues? --Xymph (talk) 06:44, 31 March 2017 (CDT)

The levels category should be on individual map pages rather than WAD overviews. At this very minute I'm making a very basic skeleton for Polygon Base, where using type L does add the author's category. --Eris Falling (talk) 06:50, 31 March 2017 (CDT)

Ah of course, thanks for clearing that up. --Xymph (talk) 07:34, 31 March 2017 (CDT)

Type/category for small mapsets?

Type 'l' adds category Level WADs, type 'e' Episode WADs, but some WADs have just two-five maps. E.g. Boothill, Deus Vult, For Whom the Bell Tolls, Galaxia, etc. Too few for an episode, so I've been using type 'l' in some cases, but then the overview page gets added to the author's levels category in addition to the individual maps, e.g. Pavel Hodek for Galaxia. And sometimes I used 'e' which isn't quite a correct fit either. But leaving out the type parameter results in the overview page getting added to category PWADs without maps, which would be far more inappropriate. My choices so far have been somewhat arbitrary anyhow.

Can we define a category for small mapsets, and what should it be named? "Mapset WADs", "Mini WADs"... any better ideas? --Xymph (talk) 13:09, 8 April 2017 (CDT)

I think "episode" is fine for 2-14 levels. --Gez (talk) 13:40, 8 April 2017 (CDT)

Agreed, I think I've seen quite a few of these WADs referred to as things like "7 map episode" by their authors. --Eris Falling (talk) 13:56, 8 April 2017 (CDT)

Seven, sure. But for two or three, "episode" sounds like a misnomer to me. The consensus on what constitutes a Doom II episode seems pretty strong. But if we agree (and I am not yet convinced) to expand the range into low numbers for the purposes of categorization, then at least its description would need to be adjusted from "are approximately" into something like "are up to approximately". --Xymph (talk) 14:17, 8 April 2017 (CDT)

My suggestion would be to create a Category:Multilevel WADs that occupies the space between 2 and 8-ish levels. --Quasar (talk) 13:41, 11 April 2017 (CDT)

Chex Quest's episodes are five-levels, why would they not be episodes? --Gez (talk) 13:58, 11 April 2017 (CDT)

I think the real problem is one of authorial intent and that trying to nail it down to numbers is perhaps futile, in light of that example. For example, a single-level wad that also includes a bonus tweaked version of the map with tons of monsters, or a myhouse.wad style level as a joke, for example, hardly constitutes an episode. But Chex Quest on the other hand was explicitly designed to function as such despite its "non-standard" level count. Part of the equation is clearly thematic consistency and/or story line. --Quasar (talk) 19:50, 11 April 2017 (CDT)

"Multilevel" sounds fine and I agree the authorial intent can be taken into account rather than settling on a fixed numeric threshold. E.g. Dark 7 sounds it was intended as a 7-map episode, while The Final Gathering and SkePLand seem to group several distinct levels, The Artifact and For Whom the Bell Tolls were merely split up because they were too big for a single level, and Galaxia's maps aren't even adjacent. So perhaps the Multilevel WADs category won't be very large, but it still serves its purpose where "episode" is a misnomer. I'm willing to do the reassignments and then individual cases can always be debated further. --Xymph (talk) 06:12, 12 April 2017 (CDT)

IMO this is completely fair.  I only wanted to make sure non-algorithmic situations could be accounted for, e.g. Galaxia's readme saying "level" even though it's two levels, or a shovelware DM compilation (some of which are notable!) which is never called an "episode" due to the complete lack of planning/coherence and all the maps having prior standalone releases.    Ryan W (usually gone) 17:54, 13 April 2017 (CDT)

Ideally we should follow the practices of the wider Doom community (extending Eris's point above).  That said, we lack an expert system which aggregates 23 years of sites and postings on demand  :>  so we must fall back on an algorithm again.  I personally am OK with any of the options above, but suggest two small things:  (1) The bot shouldn't categorize the same mod twice, in case a human editor adjusted the categorization later (based on reviews or readmes or whatever).  (2) Describe the decision tree on the category talk page, in case our successors want to re-evaluate.  US$0.02.    Ryan W (usually gone) 18:25, 11 April 2017 (CDT)

(1) Again, no bot is involved in this topic, so a hard-coded algorithm is not needed. (2) Okay. --Xymph (talk) 06:12, 12 April 2017 (CDT)

Port2

Projects like Doomworld Mega Project 2012 and its sequels feature maps built for several different ports, you've got vanilla, limit-removing, Boom, ZDoom, GZDoom and so it goes on...So far this is the only situation I've run into where the port2 parameter would be useful, but it only takes one value. Could it be expanded to take multiple values or should there be new parameters like port3 and port4 added for cases like this? --Eris Falling (talk) 07:03, 10 April 2017 (CDT)

The aim of port2 was to handle things like Doom: The Lost Episode which targets both ZDoom and Eternity. I suppose adding further portn parameters would be the simplest, if not the most elegant, way to extend this, and it'd make sense. --Gez (talk) 08:09, 10 April 2017 (CDT)

Repair and tweak

IMO two things should happen.

• Convert "Doom 2" and "Doom2" → "Doom II" in the rendered text as well as the category name.  This is not only for consistency, but the current code manages to misinterpret "Doom2" as "Doom" in the IWAD row.
• Change the cacoward parameter from an ordinal to a year, matching the Top 100 parameter.  People have already done this at times (e.g. the nomination threads), but it's now the endorsed method, and for the same reasons stated there, it ought to increase clarity.

Ryan W (living fossil) 20:39, 15 March 2018 (CDT)

Looking more closely at the markup, the first issue is actually that "Doom 2" rendered as "Doom 2".  Changing "Doom2" to "Doom" is part of collapsing the entire classic series into "Vanilla Doom", which is appropriate, therefore probably intentional.    Ryan W (living fossil) 21:59, 15 March 2018 (CDT)

The cacoward part obviously requires a mass edit to update the existing transclusions.  I doubt it will take long, but even so, I gave the parameter a default value so the cacoward boxes will hide themselves until I arrive, instead of giving an error or warning.    Ryan W (living fossil) 22:34, 15 March 2018 (CDT)

More than two ports

Velocity CTF needs three ports listed. Now we could add a port3 parameter, but we have to establish at what boundary it becomes "too much" to keep adding separate port parameters. If we feel that's been met already, then my suggestion would be to have an alternate "ports" parameter that, if provided, disables output of all the others and allows manual listing of the ports, but in turn, requires manual categorization of the article as well, since we can't parse an arbitrary input string w/o installing Lua scripting (blech). --Quasar (talk) 19:50, 2 February 2019 (CST)

The three ports being Odamex, Skulltag/Zandronum and ZDaemon, right? Perhaps a catch-all category (similar to "Boom-compatible" could be made for them. Not sure how to call it, though. "Multiplayer" is too generic because it's perfectly possible to have MP with other ports, "csDoom-compatible" is a bit vague. I'd be in favor of just adding a port3 parameter for the time being as it seems the least amount of work, and do the "ports" workaround later if it is ever needed. --Gez (talk) 13:42, 3 February 2019 (CST)

'caco' and 'top' parameters both appearing in one article

From Talk:RTC-3057, I made a change so the table column layout doesn't break when both parameters top and caco are filled. Two <td> columns for the Top 100 and two columns for the Cacoward are appearing on the same <tr> row, breaking the table layout that uses either one column (colspan = 2) or two columns on each row.

RTC-3057's demo was in the Top 100 WADs of All Time for 2003, then its Hub 1 release a year later was named to the first Cacowards in 2004.

{{wad
| name = RTC-3057
| author = Team Future
| port = ZDoom
| type = e
| iwad = Doom2
| screenshot = RTC-3057 Blue Titlepic.png
| year = 2004
| link = {{ig|id=12747}}
| top = 2003
| caco = 2004
}}

It's the only WAD that requires this template to use both parameters. Forcing the Cacoward columns onto a new row is needed.

if top is not empty
    <tr> for Top 100
if caco is not empty
    <tr> for Cacoward
if top is empty and caco is empty
    </tr> to close the Link row

--Afterglow (talk) 14:37, 12 October 2020 (CDT)

Needs a new type for gameplay mods

Per the discussion today at Talk:Partial conversion it's clear that gameplay mods are separate entities from partial conversions. Thus a new Wad template type is needed for articles like Painslayer and Corruption Cards. We also need a new Category:Gameplay mods that would be auto-populated by this new type.

On a related note, neither of these mods (or just about any GZDoom mod for that matter) are technically PWADs. They're .pk3 archives with Decorate, Zscript, multimedia resources, etc. Not exactly the same as the traditional .wad format. So perhaps they shouldn't be given WAD categories? It may not really matter, though, since they're more-or-less functionally equivalent to a WAD for the player. --PhilthyPhilistine (talk) 16:19, 21 December 2021 (CST)

Using the same template would be convenient, but the iwad[2] and port[2] parameters may not apply (in the same way) to gameplay mods as they do to mapsets/PCs/TCs. Any thoughts on this, and how to handle the distinction if that needs to be made? --Xymph (talk) 08:35, 22 December 2021 (CST)

The iwad[2] is still needed for SWWM GZ, and port[2] as well for cases like Brutal Doom that still support GZDoom + Zandronum. Would it be easier to create an entirely new template with just a subset of this one? That way it could have a param for pwad=true/false. So mods that are pwads could have the category, but pk3s wouldn't. (I just crossed this out because of noticing Category:GZDoom WADs for the first time. What I wrote is too minor a distinction to make special effort for.) --PhilthyPhilistine (talk) 08:42, 22 December 2021 (CST)

PK3 is just a different container format, it can contain maps (WAD lumps) just as well. PK3 mods with maps are categorized in Episode WADs, Megawads, etc. all the same. A separate (complex) template increases maintenance efforts, and the risk that someone picks the wrong template for their mod article.
The template now has the 'g' parameter, give it a try how that works for you. --Xymph (talk) 09:39, 22 December 2021 (CST)

Looking more closely at the current auto-populated categories for the mod articles I linked, I suggest that the new Category:Gameplay mods be a sub-cat of the current Category:PWADs without maps -- in the same way Music Packs and Texture Packs are. And for each mod article, it makes sense to retain the Category:PWADs by name they currently have. (In other words, this new template type shouldn't need much special logic.) --PhilthyPhilistine (talk) 09:26, 22 December 2021 (CST)

The new type seems to be working properly. I only changed Brutal Doom so far. Will be offline for a while but can change others later on. Thanks for adding it. --PhilthyPhilistine (talk) 09:47, 22 December 2021 (CST)

Type field instructions

The instructions for the type field currently state "the default is a gameplay mod". Since that type was just added earlier today (per the prior topic above) that statement is inaccurate. I know this because Brutal Doom's template didn't have a type field at all until I added it today. So that statement should be removed or re-worded. --PhilthyPhilistine (talk) 14:57, 22 December 2021 (CST)

Hmm, good point, the default category is PWADs without maps which is now the parent of Gameplay mods; I overlooked that. So now gameplay mods can be subcatted, leaving few (which kind?) mods in the main category? Perhaps the new type & cat took things one step too far? --Xymph (talk) 15:10, 22 December 2021 (CST)

No, I think the new cat and the new template type are the correct approach. It's always better to be explicit about these things. It may be best to leave the template code as-is and just remove that statement in the instructions. I (and others if you want to help :) haven't yet changed the template types of the gameplay mod articles (which are either 'p' type or no type at this moment). After making these changes, PWADs without maps should be empty or largely empty except the sub-cats. Is that really a problem though? It's better to have the sub-cats the way they are now. --PhilthyPhilistine (talk) 15:22, 22 December 2021 (CST)

'p' and 't' types not needed

The 'p' type for partial conversion is no longer needed. (Or, at this moment, won't be needed soon after the changes discussed in the prior 2 sections here.) The reason is that PCs are now defined as map(s) + other stuff (gameplay changes and such). Thus any PC is also a map and categorized with one of the map types. Likewise, 't' for total conversion is also redundant. Taking a quick look at several TC articles, they use the proper map type already. --PhilthyPhilistine (talk) 17:54, 22 December 2021 (CST)

Mods can have type p/t and cat episode/megawads in the footer, or vice versa with type u/e/m and cat PC/TC. The size category ensures the mod appears in the group with mapsets of similar size. How that is defined isn't terribly important, but this wad template needs to continue to support all types. --Xymph (talk) 03:40, 23 December 2021 (CST)

So are you saying the template can support multiple type values? Otherwise a TC is going to use the appropriate map type. And, based on last night's discussion with Quasar, who knows what a PC actually is/was. (So in that vein, it makes sense to keep 'p' around until that ever gets sorted out.) --PhilthyPhilistine (talk) 13:05, 23 December 2021 (CST)

No, but using one type in the template doesn't preclude adding another category in the footer of an article... --Xymph (talk) 13:17, 23 December 2021 (CST)

Gotcha, one can use the 't' type and manually add the map type category. Okay, no need to change things for editor flexibility. --PhilthyPhilistine (talk) 13:19, 23 December 2021 (CST)

I've been doing it the other way around, since all mapsets have some size type, but not all are a PC/TC. So it made sense to me to make that the 'extra' category, which then gets sorted later/last in the page footer. --Xymph (talk) 13:22, 23 December 2021 (CST)