The Backpack is categorized a powerup in Doom tables, while the Bag of Holding is considered a collection of ammo in Heretic tables. I have a mild preference for the latter approach. What's odd here is that the Bag of Holding is a powerup in Heretic (it's one of the items that are counted for collection in the end of level statistics) but not in Doom. --Gez (talk) 17:44, 5 August 2016 (CDT)

Ah, good point. So you suggest to put the Backpack with the Ammo class, and the BoH with the Items? Or both with Items?
That also invalidates a separate Health/Armor class, I suppose, since some of those are Items too.
Any other suggestions? --Xymph (talk) 03:00, 6 August 2016 (CDT)
I'd say put both in Items. The Bag definitely is one, and the backpack doesn't behave exactly like an ammo pickup (for example you can pick up backpacks even if your ammo is already fully maxed out). Health and armor would include things such as medikit, stimpack, crystal vial, silver shield, amulet of warding, etc. but health bonus, armor bonus, berserk pack, quartz flask, and dragonskin bracers are items.
Basically my "item" litmus test is this: if it's counted up as an item on the intermission, goes in your inventory in Heretic or Hexen*, and/or is always picked up when you run over it, it's an item. (Unless it's a key.) [*In Strife pretty much everything goes into your inventory, so this criteria is only for the Raven games.] --Gez (talk) 03:13, 19 August 2016 (CDT)
Alright, it still feels a bit unnatural to me that some health/armor would go into another class, but the intermission count is a stronger argument. See the updated tables. Rad suit also isn't countable, but it makes no sense to put it anywhere else either.
That brings me to another detail; what should the class header be: Items, Artifacts, Powerups, or even Power-ups? Currently Doom and Strife use Powerups, Heretic and Hexen use Items. But in the latter, that's (too?) close in naming to the next class 'Puzzle items', and Strife has 'Quest items'. The Item page also mixes all those terms including dash/no dash in Powerups. Thoughts? --Xymph (talk) 08:58, 19 August 2016 (CDT)
Items is generic enough IMO. Puzzle/quest items I would actually fold into keys ("Keys and puzzle/quest items"), since that's basically the purpose they serve. --Gez (talk) 17:20, 24 August 2016 (CDT)
Good, but for Strife I'd move the various coins pickup out of K&QI and into the generic items. I'm not sure it makes sense to refer of gold as quest items in the first place since I don't believe there are any Strife quests that require you to have money. --Gez (talk) 06:52, 25 August 2016 (CDT)
Re: merging puzzle/quest items with keys, good idea, see the updated tables and sample maps. And Strife gold was classified that way because of this list but I'm fine with moving them.
So, if there are no further suggestions, then I'm considering the classes and their entries final, apart from Strife's minor character problem I outlined at the end of my update today. Any feedback on that? --Xymph (talk) 09:37, 25 August 2016 (CDT)
The minor characters could possibly be handled with templates, so that the spaghetti code would be handled on the wiki's side. I'm thinking of something kind of like this, which could switch on the {{PAGENAME}}, so for example {{Peasant133}} would appear as [[Worner]] on MAP04: Power Station (Strife), and just as Peasant Red 3 on every other page; or for another example {{Peasant130}} would appear as [[Strife minor characters - Hub 1#Arion|Arion]] on MAP02: Town (Strife), as Technician on MAP04, and as Peasant Tan 2 on any other page. Technically it's possible on the wiki's side, so the question is whether the other admins are okay with me creating 22 switching peasant templates and if your program is okay with having some thing types use curly braces instead of square brackets. First thing first, though, we'll need a recap table summarizing which peasant appear on which map and which name they have there. --Gez (talk) 10:54, 25 August 2016 (CDT)
Very interesting idea. DMMPST can easily output something different for the character names, see the table update. Currently I've spaced out the curly braces to avoid dead template links, but it's trivial to unspace them. The only (minor) downside is that when a Const template displays a thing as Peasant XYZ, it cannot conditionally wikilink only the first such entry – it would have to be all or none. I think none is acceptable here.
A table of minor characters for each Peasant is available on their page. I'm barely familiar with Strife so I'm not sure it's completely accurate, and cross-checking with the relevant (or all) map pages may be prudent. Also, in SLADE3's things_strife.cfg file one Rebel and one Beggar are also listed with alternate minor characters, so for consistency I've parameterized them all – 33 in total. And I moved the Kneeling guy and Zombie (spawner) to the end of that class. If you can attain sufficient admin consensus and then create those Const templates, that would be most helpful. --Xymph (talk) 14:32, 25 August 2016 (CDT)
I think we need to deindent a bit...

Okay, deindenting. The peasant table is a good starting point, but it's not complete unfortunately. (E.g. Ulaine isn't on it.) Also we're running into a secondary issue -- how to identify peasant types consistently? If you look at this for example, you'll see them identified as type 6 and type 15 -- those are the conversation IDs. There are also the editor numbers, and the ZDoom actor classes (which is Peasant with a number suffix based on their order in the executable, which means it's the same as the conversation ID minus 5). And there's what you've been using so far which is yet again different, based on their color and a count for this color in particular. --Gez (talk) 14:50, 25 August 2016 (CDT)

I wasn't really aware of conversation IDs, but I see your point. I found this list that may help but still have no idea how to find those IDs in the source code, and relate them to Things. I'm not sure what you mean by me using colors though; the tool counts by Thing IDs (DoomEdNums). The comments next to these actor lists provide another list of maps they appear on.   Anyway, you are probably far more familiar with those links and this entire subject matter than me. Having been mostly out of DOOM-land for nearly two decades (and knowing Strife least of all four main titles) means that I can use all the help you (and others familiar with Strife) can provide. I've learned a lot in the past few months of wiki contributing, but by no means pretend to now be able to solve long-standing issues single-handedly. So, how would you propose to move forward? --Xymph (talk) 15:36, 29 August 2016 (CDT)
The conversation ID is simply the mobj type's index in the mobj type table. It's the same thing as the dehacked number for Doom classes. That's also why some things have different conversation IDs depending on the version (first teaser, second teaser, full game), as some classes were added or removed. For the color thing, I'm just referring to how you had named them such as "Peasant Red 1" and so on. --Gez (talk) 20:05, 29 August 2016 (CDT)
The colors came from my aforementioned sources. Thanks for the ConvID clarification; I presume then that the IDs used in the wiki are those of the full game.
Since you avoided the most important question ;) I decided to move forward by compiling a complete table per map of Thing IDs and names, conversation IDs and wiki links. Once that is done, I'll see if it's feasible to include those relationships into DMMPST in a (reasonably) clean way, so that its output will refer to actors with unique dialogue by their proper name with the appropriate wikilink. That would address the concerns like conditionally linking the first entry and preserving Jartapran's info, while keeping the tables more human-readable than with const templates. --Xymph (talk) 06:52, 8 September 2016 (CDT)
The translation table is ready as per the latest status. Unless there is more feedback, I consider DMMPST's generation of Things tables with their classes and entries in this order to be final and ready for production. --Xymph (talk) 16:51, 14 September 2016 (CDT)


Five tables side-by-side for Hexen is perhaps a bit much, so maybe something should be made collapsible, or the multiplayer tables should be below the singleplayer ones? It might be possible to adapt the maptab template to put each table in a different tab? --Gez (talk) 11:37, 14 August 2016 (CDT)

Do you want me to give it a try? I think I know what failed. Look below for the hoop I'm jumping through:

Tab with tableOther tab
This table should work
I guess I hope

As you can see, since everything is in a template, all the pipes (|) are interpreted as argument separators for the template. The solution is to use {{!}} for every pipe character that isn't an argument separator for tab2. It's a special magic word. (It used to be a common template before that, but I discovered when trying to use {{tl}} to link it that it wasn't one anymore.) Anyway, I think I can make it work. --Gez (talk) 15:49, 14 August 2016 (CDT)

That's an interesting suggestion, but then with its parent Tab2 template. Unfortunately, my first two attempts failed miserably – Quasar wasn't kidding that this tab stuff takes a lot of effort to get right. That was before I saw your response above, so I copied this one to a new edit window so as not to overwrite that. :)
My initial approach would be to put Hexen's three single-player tables in the first tab, and the two multiplayer ones in the other. There are no Tab3 and Tab5 templates, and since three tables do fit well enough within reasonably sized browser windows, it seems overkill to put each table in a tab. Especially if this is to be applied consistently to all games and vanilla Doom/Heretic maps use just two tables. How this works out on mobile devices is another matter though.
So, with your timely reminder about the |->! escape, this might work as yet, though the whole thing would become pretty unreadable and difficult to edit manually – but still easy to generate via the tool. I'll give it a go.
However, DMMPST so far is able to process all games in a generic way with a single Things template and some decision logic in the code. Breaking up Hexen's tables into two groups would make that much harder, if not require a separate processing branch – which I really would like to avoid.
PS. Your offer of tab-help is appreciated, but I would be helped even more by a response in the main discussion topic. --Xymph (talk) 16:18, 14 August 2016 (CDT)
I'm not sure exactly what is the main topic here, since this has all been spread about everywhere, as you noticed. On central processing? --Gez (talk) 18:04, 14 August 2016 (CDT)
The most recent and all-encompassing one you initiated, yes. --Xymph (talk) 01:41, 15 August 2016 (CDT)
Unfortunately I cannot endorse this idea of using maptabs for important article content because of the fact they do not work on mobile, at all, nor can they be made to do so. When a maptab template expands on mobile, only the tab marked as the default tab (this is, by default, the first tab defined) will be written to the article and the rest are discarded by necessity of it being impossible to redefine a flowed layout for an arbitrary number of floating elements where the use of JavaScript is supposed to be minimized. The justification for this with regard to the maptabs in particular is that having the unmarked non-walkthrough version of the map image is in no way critical to end-user experience when reading a map article. On the other hand, hiding four whole tables worth of information from mobile users is unacceptable. --Quasar (talk) 15:26, 25 August 2016 (CDT)
I agree that 80% invisible tables would be unacceptable, but there may be a little misunderstanding: my approach is to put the three single-player tables in one tab and the two multiplayer ones in the other, and I already covered the mobile issue in my discussion of that. The question remains whether invisible multiplayer tables only (40%) may as yet be acceptable? There are also two formatting complications (the params to col-break and prettytable not working), maybe you can find a solution for them? Alternatively, if tabs are still unacceptable, what do you guys think of the two-row approach? --Xymph (talk) 16:45, 25 August 2016 (CDT)
← unindenting ←

The two-row approach seems fine, though I don't actually mind a single row either if it doesn't cause layout issues in some cases (I imagine it might be too unwieldy on mobiles). --Gez (talk) 18:52, 1 September 2016 (CDT)

For now I agree. This can be revisited perhaps if I find a way to make tabs work on mobile. --Quasar (talk) 10:57, 7 September 2016 (CDT)

Thanks for your feedback (at last ;)). Five tables on one row is only acceptable in full-width desktop browsers, but I keep my browsers at about 2/3 screen width (with room for a terminal window or another application next to it), and then the tables become way too cramped. Further, the tabbed version is hardly human-readable due to the escaped |'s, and has two layout issues, only one of which can be addressed at the expense of making the tables even less human-readable. I feel these are bigger downsides than the page real estate taken up by two rows of tables.
All in all, I chose the two-rows approach and now implemented that in DMMPST. --Xymph (talk) 06:52, 8 September 2016 (CDT)
I dunno if it helps now, but MediaWiki supports HTML table markup just fine as an alternative to wiki table markup. I almost always resort to use of HTML table markup when working inside complex templates just due to the readability and maintainability issues that you're noticing here. --Quasar (talk) 09:33, 8 September 2016 (CDT)
That's good to know, but for all table situations apart from Hexen's in tabs, the wiki table works fine and is more human-readable than an HTML one, where I would need to define more styling myself. And using one markup for one game and another for the other three is certainly not an option (although you probably didn't intend that anyway). --Xymph (talk) 16:51, 14 September 2016 (CDT)

List of things[edit]

Since you've added the stealth monsters, you should probably add also the MBF dog (888) -- it's used at least in Valiant (where is is dehacked into an arachnorb). --Gez (talk) 17:15, 18 August 2016 (CDT)

Soitenly. And while you're here again, could you answer my question above? Otherwise I'll assume that the current classification of both items is fine. --Xymph (talk) 02:09, 19 August 2016 (CDT)

Misc. things and player starts[edit]

Voodoo dolls could be counted -- they are merely the number of player 1 start points minus 1. If there are three player 1 starts, there are two voodoo dolls. Coop starts could be counted too, but here again the mechanics is a bit different. If there is one (or more, see voodoo dolls) P1 start, one P2 start, and one P3 start, that's three coop starts. See player start (ZDoom wiki link because we don't have such an article here yet) for a list of editor numbers. Finally, there are team game player starts, notably the CTF Standard defines red and blue team starts. --Gez (talk) 09:42, 17 October 2016 (CDT)

Players starts normally seem skippable to me as there is only one of each. Voodoo dolls are an interesting exception, but it's not entirely clear whether multiple player #2, #3, etc starts create dolls for those other players too. DW indicates that's the case but they're rare, the ZDoom page describes only #1. Could this theoretically result in up to 8 Voodoo doll rows in the Things table? That's a bit much, innit? How many maps that are likely to be described on DW do even have them?
And as mentioned long ago (in the context of combining Strife's acolytes and rebels and such), any aggregation or computation on the normal total number of a Thing would require special handling in the generic counting and/or table building code, which I really want to avoid.
Team starts present a different problem: after checking a few CTF maps that follow an older convention (red 9027, blue 9029) I found Rage CTF uses the new standard, but also uses Hexen's lump formats. In DMMPST the IWAD determines how thing and linedef lumps are loaded, and this PWAD's lumps aren't compatible with Doom II's. Being relatively new to these source port details, I don't know if that's always the case, or whether there are also CTF levels in Doom lump format. But all in all, this becomes a little awkward to code for as well.
Btw, the Standard editor numbers list doesn't mention those IDs. Lastly, got a class header preference? --Xymph (talk) 08:54, 18 October 2016 (CDT)
I wasn't talking about listing separately each coop player start type, but about telling how many types were present. If there are player starts for player 1, 2, and 3, then it's three players coop. If there are starts for player 1, 2, 3, 4, 5, 6, then it's six players coop. I do think that'd be useful to know.
Given how the multiplayer scene is largely focused on ZDaemon and Zandronum-née-Skulltag, you're going to find a lot of DM/CTF levels using the "Doom-in-Hexen" format. Also most ZDoom singleplayer maps, as well, such as the Zort series for example. There are CTF levels in Doom format, though, look for odactf1 for example.
As for class header, either "Miscellaneous" or "Hazards & Misc.", I have no strong feelings about this either way though. --Gez (talk) 06:30, 20 October 2016 (CDT)
Hazards had just a category link anyway, not an informational page, so no reason to let that stand out over all the other misc. things. "Miscellaneous" it is.  
Thoughts on how to count voodoo dolls?
In which table should the Team starts be included? Only Boom/Hexen Deathmatch, or Coop too, or even classic MP? --Xymph (talk) 03:02, 22 October 2016 (CDT)
Voodoo dolls: I'd say only one count is needed. Team starts: Deathmatch if available, Multiplayer otherwise. I don't think any multiplayer-centric port out there lacks Boom support, though, so you're probably fine with just Deathmatch. --Gez (talk) 05:03, 24 October 2016 (CDT)