Difference between revisions of "Template talk:Wad"

From DoomWiki.org

(Three ports issue)
(More than two ports)
 
Line 49: Line 49:
 
== More than two ports ==
 
== 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). --[[User:Quasar|Quasar]] ([[User talk:Quasar|talk]]) 19:50, 2 February 2019 (CST)
 
[[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). --[[User:Quasar|Quasar]] ([[User talk: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. --[[User:Gez|Gez]] ([[User talk:Gez|talk]]) 13:42, 3 February 2019 (CST)

Latest revision as of 13:42, 3 February 2019

Author cat bug[edit]

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

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

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

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

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)