Doom Wiki:Central Processing/2016

__NEWSECTIONLINK__

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.

Link archiving
I have created a series of new templates for semantic link archiving and and a help page that explains how they work. --Quasar (talk) 16:30, 1 February 2016 (CST)

Webfonts
The MIT-licensed version of Glyphicons Halflings and the (somewhat vaguely) open-source Iconochive fonts are now pushed out through our Common.css, allowing use of the various icons they contain. Right now you need to know the magic Unicode numbers but we can address that through either templates or CSS rules, depending on how much we value IE8 support (the CSS :before selector cannot insert content in that browser, which is the typical strategy used for this). --Quasar (talk) 16:30, 1 February 2016 (CST)

Promotion for Nukeykt
Fraggle would like for Nukeykt to have editor rights, in lieu of waiting for autopromotion. I am opening discussion here. --Quasar (talk) 16:30, 1 February 2016 (CST)
 * I have no objection. --Gez (talk) 16:41, 1 February 2016 (CST)

Marked spots?
Gez enlightened me on what tools generate the maps deployed in this wiki, but this seems a general issue so I'll pose it here rather than to him directly: many level walk-throughs refer to "marked spots" on the accompanying map, but quite a lot of maps don't actually show those spots. Is this being discussed or addressed? I searched but didn't find a previous topic about it. --Xymph (talk) 04:39, 18 February 2016 (CST)


 * Doom Wiki:RFC/Maptabs template is relevant. The intention is to make such walkthrough images alternatives to the normal map images and make both available through this template. However, I do not have the patience required to redo the CSS on the tabs template because it took literal weeks to get it working. Since there is negative consensus on the current appearance, the RFC has stalled. --Quasar (talk) 12:04, 18 February 2016 (CST)


 * I love that template, but I think this is about its prerequisites, i.e. how do we get the "dotted" images uploaded in the first place? The short answer is no, there is not currently an ongoing project (unless someone is doing it secretly).  The only previous thread I recall is here; in addition to what I told that guy, it is not purely a clerical task, because you have to examine the level sufficiently to match the 2D locations with their architectural descriptions in the text.  Like many aspects of map articles, improvements can and should be made, but it takes time and concentration to do correctly.    Ryan W (talk) 16:26, 18 February 2016 (CST)


 * Yes, I was more curious about the latter, but thanks both for further enlightenment. :) --Xymph (talk) 02:41, 19 February 2016 (CST)


 * I've suggested a simple change to (hopefully) revive and wrap up the maptabs RFC. Also, I encountered the original topic where the markers were introduced, linked here for reference. --Xymph (talk) 15:57, 24 April 2016 (CDT)

Should go without saying...
Please do not place multiple right-floating elements next to each other when authoring pages. Most of these happened a long time ago but a few are recent. General rule, if it looks funny to you, it's funny :P --Quasar (talk) 14:00, 25 February 2016 (CST)
 * This can be dependent on browser window size, zoom level, font size, etc. so sometimes it'll look fine on your computer and wrong on another. A long time ago on UESP I got in a dumb edit war because of that: I'd tweak a page's layout to look great on my screen and then someone else would come and ruin everything for me by making it look great on his screen. :p --Gez (talk) 16:36, 25 February 2016 (CST)
 * True, always a consideration. --Quasar (talk) 21:24, 26 February 2016 (CST)

Console level template deletions
As per consensus reached to move multiple competing article-top-right-corner nav templates related to console levels down to the bottom as wide navboxes, the following templates are now unused and I have nominated them for deletion. The top-right role will be replaced by a console level progression navigator that lets you move backward and forward to the previous or next map for the specific console you want to follow, which we felt was the primary motivator for these templates to begin with. --Quasar (talk) 16:38, 2 March 2016 (CST)


 * Yeah, delete. These templates indeed appear to be superseded by the new wide navboxes, and have been replaced by them in all articles.  (Still not sure how that happened so quickly...)    Ryan W (talk) 23:05, 4 March 2016 (CST)


 * Pretty much uncontroversial cleanup, so I went ahead with it. --Quasar (talk) 19:27, 17 March 2016 (CDT)

Banning and IP blocking procedures
Due to the rash of spam we opened up the CheckUser ability to some sysadmins. It is important that procedures continue to be followed as they were previously, however: --Quasar (talk) 01:14, 3 March 2016 (CST)
 * If a user account spams, that user account must be blocked. Creating an IP range block that covers them does not ban any accounts they already created.
 * IP rangeblocks should only be set to prevent account registration when a spammer has actually registered an account from that range, not just because spam came out of that range from anonymous IPs. This is what our captcha exists for - to allow constructive human editors to have a chance of getting past indiscriminate IP blocks. If you go back to all the rangeblocks I did, *only* ranges that had accounts registered from them ever had "prevent account registration" selected.
 * IP rangeblocks in areas likely to contain constructive editors must be temporary. Anglosphere countries, Western Europe, or Russian dynamic IP ranges should not be permanently blocked. Chinese, Indian, Philippine, Ukranian, Russian private /24 networks, and dedicated hosting companies should be permanent blocks. This is obviously on a case-by-case basis but my rule has been the less likely an area is to be constructively editing or even having any interest at all in our site, the longer the block. A general scale I go by: US/English-speaking/Western European dynamic range: weeks to 1 month block at most. Eastern European or various other less likely areas: 2-6 months.

Console map articles: going forward
So, from the recent mass edits, I infer the following.


 * SNES Doom and GBA Doom II don't need separate map articles, because some effort was made to match the originals. Any changes can be described in a section of the PC map article.
 * Doom Classic, Windows CE, and Tapwave Zodiac are even closer conversions, and should be assumed identical (aside from global differences listed in the main article), barring some unforeseen technical research.
 * Stock PC maps go into Category:Levels with console versions only when a separate console article exists (or is redlinked).
 * Category:Stock levels with multiple names may include redirects for ease of navigation. We don't normally categorize redirects, but I can see the point in this case.

Does that make sense? I personally don't have big plans for this content, but presumably others do :>  and also I'm thinking of how best to react when a newbie creates a page, or when working on related PC articles. Ryan W (talk) 15:26, 5 March 2016 (CST)

--Quasar (talk) 05:38, 17 March 2016 (CDT)
 * Do not necessarily agree on SNES and GBA Doom 2 as a blanket statement. Not all levels in those ports are sufficiently modified to require a new article. But some are substantially modified. GBA Doom 2 has heavy modifications - a couple of the levels are even divided into two maps! I'll make this call if and when it ever becomes possible to acquire maps for the levels in these ports - it is not currently possible.
 * Ports that are only using the PC WAD do not need level articles. Those are direct ports using the same data, not new levels.
 * The category contains redirects because without them you cannot see what the alternate names are.


 * For the SNES case, Ledmeister seems to have them, although he doesn't explain what the secret sauce is.   Ryan W (talk) 16:12, 18 March 2016 (CDT)


 * Right, unfortunately they're not in our preferred OMGIFOL/SLADE color scheme and we also do not presently have a content sharing arrangement with him. --Quasar (talk) 16:12, 20 March 2016 (CDT)

Articles to be merged
needs attention. It is perpetually growing without anyone ever giving input. A few weeks more on some of these and I will just execute them unilaterally. --Quasar (talk) 05:38, 17 March 2016 (CDT)

Standard map sections?
While editing walk-throughs of the Final Doom maps I played, I have been standardizing the section headers, but along the way learned that there seem to be two standards, at least for the main strategy / walk-through area. One used on e.g. E1M1 - E1M9, E2M1 - E2M5, E2M9, E4M1 and a similar cross-section of Doom II maps: Another used on E2M6 - E2M8, E3M1 - E3M9, E4M2 - E4M8 (and ditto D2 mishmash): Why do the different variants exist? Which one is preferred or recommended? Where is the template used to initiate new pages for maps? The one frequently used by e.g. MtErebus adheres to the first standard above. Is this topic already discussed elsewhere (I searched in vain)? --Xymph (talk) 12:48, 20 March 2016 (CDT)
 * 1) Walkthrough
 * 2) Essentials
 * 3) Other points of interest (optional)
 * 4) Secrets
 * 5) Bugs (optional)
 * 6) Demo files (optional)
 * 1) Strategy
 * 2) Walkthrough
 * 3) Other points of interest (optional)
 * 4) Secrets
 * 5) Bugs (optional)


 * AFAIK, most map articles are created by substing the map skel template, which corresponds to the first model. The second model seems older, since the map skel template started with a "strategy" header with "walkthrough" and "secrets" as subheader, and then here changed mostly to the first model. --Gez (talk) 13:02, 20 March 2016 (CDT)


 * Bummer, I usually standardized towards the other one, or at least didn't convert when the opportunity arose. Somehow the latter model seemed newer, more common and more sensible to me. Well, I'm not going back just to tweak earlier edits, but will keep it in mind going forward. Thanks. --Xymph (talk) 13:30, 20 March 2016 (CDT)


 * Note that, due to the recent inclusion of other templates within map skel, simple substing no longer works: you must copypaste from one edit window into the other. This is counterintuitive and produces well-intentioned errors, so I keep meaning to research it further (MediaWiki has, I believe, some equivalent of preprocessor directives which would generate the intended output in one step).    Ryan W (talk) 14:19, 20 March 2016 (CDT)

Supercharge over Soul sphere?
Although the pick-up message for the Soul sphere is: SUPERCHARGE!, I've never heard the power up itself being called a supercharge itself, and instead I thought the message describe what the powerup did as in a supercharge of health. It is more commonly reffered to as a Soul sphere. I'm new to this wiki and I'm not sure how to move the page. Thanks


 * Hi. A change like this generally would not be made before consensus is reached in a discussion here. There are a number of such ambiguities in the Doom series where things have more than one canonical name, and one or the other were chosen, sometimes without deliberation or regard to any particular standard. However generally preference was given with these old articles to the text used in-game, in preference to text that appeared in the manual, on the theory that id Software may not have been as involved in the manual's production, making it secondary canon to the game itself. This is not an unusual approach in other gaming communities; Castlevania is plagued by such issues, where the story in the manual doesn't match the game or the original Japanese version. Right now we have Supercharge as the article title, and soul sphere is a redirect to that, so writers are still able to call the item by whichever name they prefer and as far as I know there is no objection to doing this except where it creates stylistic inconsistency (ie., switching arbitrarily between the two names within the same article). --Quasar (talk) 11:11, 8 April 2016 (CDT)

News board tweaks
Our News board now validates as schema.org NewsArticle microdata entries, as well as the hfeed/hAtom microfeed it previously supported, which Google and other search engines can use to build "AMP articles". Dunno if they'll pick up on it and actually do that, but the capability is there. As a result though, if you want to put a right-floating thumb in, you need to use the new pic/w/h parameters of the news article header template or else the image isn't visible as being related to the article. I hate making something complicated even more so but it was unavoidable because microdata is really inflexible. --Quasar (talk) 11:55, 12 April 2016 (CDT)

Baron of (H|h)ell
User:Who is like God? moved Baron of hell to its lower h-e-doublehockeysticks location back in 2008 but consensus since then has been that we treat Hell as a proper noun anywhere it's not being used as a quoted swear word ("go to hell", for example), so arguably this move was incorrect in the long term. Moving it back at this point (Making Baron of Hell the main article title, and Baron of hell a redirect to it) will require fixing up the following redirects, however, so that they don't become doubles: Is there consensus for this? The article title doesn't even currently match the bolded text in the first paragraph, so far has the consensus shifted. --Quasar (talk) 12:32, 12 April 2016 (CDT)
 * Baron
 * Ogre
 * Bruiser Brothers
 * Barons


 * I dimly recall contesting that move, but now can't find the thread. The reasoning in our current guideline seems sound: Hell is capitalized because it's a place name, e.g. .  Should this be agreed upon, I'm willing to search for other instances in body text, and try to make them consistent.    Ryan W (talk) 19:11, 13 April 2016 (CDT)


 * Makes sense to me. And welcome back to Ryan. ;) --Xymph (talk) 02:22, 14 April 2016 (CDT)


 * Agreed. --Gez (talk) 07:14, 14 April 2016 (CDT)


 * As already stated before on this site, I strongly agree --SuperShotgunPenguin (talk) 13:31, 19 April 2016 (CDT)

I'll double down here and note that I never suggested here that "Baron" should be capitalized everywhere. This was about the word Hell. --Quasar (talk) 12:06, 8 May 2016 (CDT)


 * That's indeed how I interpreted the outcome here when occasionally updating baron of [h->H]ell refs in Final Doom walkthroughs in recent weeks. --Xymph (talk) 12:55, 8 May 2016 (CDT)


 * The previous two posts refer, presumably, to this edit which I have now adjusted. As noted on IRC, our current practice is inconsistent but the preferred convention is not entirely clear either ("baron" in non-Doom contexts can be capitalized or not).  So I tried it, and apparently messed up, but at least there was feedback for once.      Ryan W (talk) 19:41, 9 May 2016 (CDT)


 * We might as well open the nasty discussion I've always dreaded on how we want to treat the phrase "Baron of Hell" when it occurs in full, since we're currently inconsistent with it even within single articles. I still prefer the full phrase to be capped when it occurs like this, because it feels like it is the title of the monster being discussed and not a mere species name, to me. But also, it's a matter of aesthetics:


 * Baron of Hell
 * baron of Hell
 * Maybe it's just my OCD kicking in, but the latter looks unbalanced to me, and therefore ugly to read. --Quasar (talk) 23:45, 9 May 2016 (CDT)


 * I sorta agree with the unbalanced aspect, but all other monsters are also mentioned as individuals (e.g. in walkthroughs) yet the consensus is not to capitalize their names. Why would "the Baron of Hell" in full be a title but "the cyberdemon" or "the arch-vile" not? Is it because it "lords over" a place, and is that strong enough to make an exception just for this monster?
 * Wish you hadn't dreaded this til past my combing the Final Doom walkthroughs. ;) --Xymph (talk) 02:56, 11 May 2016 (CDT)
 * It only looks unbalanced because of the list presentation, the issue is not as visual when barons of Hell are just mentioned inside a proper paragraph, just like you could mention earls of England and dukes of Denmark. Lists tend to have their items capitalized anyway even though the words themselves wouldn't be in paragraphs:


 * Strawberry
 * Banana
 * Apple
 * Coconut
 * So I don't see this as a problem. --Gez (talk) 03:22, 11 May 2016 (CDT)


 * On reflection I agree with this. A related recent case was gameplay navboxes, where initial capitals belong on article titles even when the subject itself is a common noun (e.g. shotgun, door).  Maybe there could be edge cases involving the rank of a specific individual ("Oremorj, the Cyberdemon Lord"?) but 99.99% of the time we refer to a thing as an interchangeable member of a class, matching Gez's examples.


 * In formal writing, arguments from OCD are often valid :>   but not here IMO.  Lowercase species names "looked unbalanced" to me once, so I started capitalizing them.  As Quasar states, a consensus on lowercase then emerged over time (eventually I'll go back and mop up, unless someone else does first).  I'll get used to this one too.    Ryan W (talk) 11:00, 12 May 2016 (CDT)

Article on Super chaingun?
Would it make sense for a page about the Super chaingun (the weapon used by the Spiderdemon, according to the manuals)? Or are the manuals not good enough sources for it to be distinguished as a separate weapon from the Chaingun? thanks. --SuperShotgunPenguin (talk) 10:35, 13 April 2016 (CDT)


 * Consensus is only to discuss enemy attacks on the enemy's page itself. The weapons wielded by enemies can be adequately described there. I believe the "super chaingun" bit is already described on Spider Mastermind. --Quasar (talk) 17:35, 13 April 2016 (CDT)


 * Agreed. It would be one thing if that gun had become a DeHackEd fad or something, circulated widely among modders in certain countries, but that's not so.  Monster weapons simply don't have enough content, separate from what we already say about the monster's combat behavior, for separate articles.    Ryan W (talk) 19:15, 13 April 2016 (CDT)

Navbox template font size?
It struck me that the font size for episode navboxes is inconsistent: an incomplete random check of entries on Category:Navboxes for map articles indicates that the majority (including those for Doom II and both Final Doom iwads) use default font for the header and 'div style="font-size: smaller"' for their contents; some however use 'div style="font-size: larger"' for the header and default for the contents. Which one is the standard / preferred style? The larger style (e.g. in Template:Hell's Gate - The Red Spot) looks to take up too much space for my liking, but it also happens to be the one used for the Ultimate Doom episodes, so I'm not going ahead and change it without discussion and (hopefully) consensus. ;) --Xymph (talk) 14:50, 18 April 2016 (CDT)
 * Normal header and smaller content, IMO. --Gez (talk) 15:13, 18 April 2016 (CDT)


 * The "smaller" font size is a real problem for mobile view, which now accounts for 25% of our viewership. Something to think about. I am not really concerned with the headers, but the use of "smaller" on lists of links creates tap zones that are too small to effectively use at all. --Quasar (talk) 15:49, 18 April 2016 (CDT)


 * I looked at the site on my tablet for the first time (in mobile & desktop modes), and I have to agree. But I don't normally visit the site on anything but a PC, and I'd still like the smaller fonts/boxes there. I'm also a stickler for consistency. ;)
 * So what can be done? Is it possible to differentiate between platforms and present different sizes via CSS? --Xymph (talk) 03:53, 19 April 2016 (CDT)


 * It is, but the templates would have to be changed to use a CSS class. We'd then define that class to apply font-size: smaller in Common.css, while leaving it normal in Mobile.css - this allows the two to present differently depending on the view being used. --Quasar (talk) 09:44, 19 April 2016 (CDT)


 * Well, that's a lot of templates to tweak, but they don't all have to be done at once, and I'm willing to assist as I brought it up. ;) Can you make the necessary CSS additions, and changes to a 'prototype' template? --Xymph (talk) 15:13, 19 April 2016 (CDT)
 * Quasar, since you seem to be the only one making CSS changes, is this little project still on your to-do list? (And the Maptabs template tweak(s) too?) --Xymph (talk) 09:17, 19 May 2016 (CDT)

Backups, dumps, archives, etc.
On a related note, and I realise you have not ended up being in this position on purpose, but we are basically one person deep (bus factor: 1) on important things like site resilience, which is why I've been banging on about backups and data dumps for a long time. It's all fine and well to assure us that all is fine, but I would be much happier if I knew *I* had a dump of everything myself, and worst-case scenario, some crazy bus driver takes you out, takes Mike out and steals Mancunet's hard drives, I could get the thing back up again myself. Or anyone could. -- Jdowland (talk) 09:49, 19 April 2016 (CDT)


 * This is straying from the original topic and would be served by forking it under a separate header. I took the liberty of doing that, hope Jdowland doesn't mind.--Xymph (talk) 10:08, 19 April 2016 (CDT)


 * Not at all -- I've just moved the whole section to Central Processing which is probably where it belongs anyway. Thanks! -- Jdowland (talk) 03:27, 20 April 2016 (CDT)


 * Anyway, I can confirm that wikis do die because of bus factor 1, as www.tm-wiki.org (for TrackMania) went down last year and the only person controlling the server didn't respond to emails, not even from the (different) person that controls its DNS entry. Not saying that DoomWiki's resilience is badly handled now, as I know nothing about that, but if there is concern about it then I can understand that. --Xymph (talk) 10:08, 19 April 2016 (CDT)


 * Nothing stops anybody from making incremental dumps of this site via the MediaWiki API. I would suggest you do so at a retrieval rate that does not tax the server though. As stated before there is no process available to me to make safe dumps available. There is no MediaWiki script that will dump the user table columns for salted password, email address, and current session ID. So unless you want everyone's user accounts to be hacked and emails harvested for spam, please don't suggest that I upload an unstripped dump. --Quasar (talk) 10:27, 19 April 2016 (CDT)


 * Thanks Quasar for your patient, reasoned response. You are right and those are things I should really focus on. I will get back in touch with you about which IP and how frequently an API dump will be performed to make sure it's coordinated. But my main effort will be on sorting out a script for getting a scrubbed dump reliably. -- Jdowland (talk) 03:27, 20 April 2016 (CDT)


 * FWIW, I get API dumps with . I did the first one with Manc watching on IRC, and he said the load was negligible and never mentioned IP addresses.  I assume a skilled programmer could modify the code to download any supported metadata (e.g. username lists), which would still be less than a full SQL dump, but decrease the pain of a (hypothetical) fail-safe fork.    Ryan W (talk) 18:09, 20 April 2016 (CDT)

QueryBot can now edit
I've successfully written code that can automate simple types of edits and apply them through the User:QueryBot account. I finished using it to recategorize 142 images that were in the category and distribute them properly into  and. --Quasar (talk) 14:15, 20 April 2016 (CDT)


 * WOW! A large milestone for us.  And hopefully people won't expect you to take all mass edits off their hands.  :D    Ryan W (talk) 18:26, 20 April 2016 (CDT)

Map thing statistics
I'd like to establish some sort of new standard for filling up the map things tables, one that is inclusive of multiplayer and of Hexen. Problem: there's a lot of cross-referenced infos and we're limited to two-dimensional tables. Here are the basic issues: a thing can appear or not depending on the following filters: Currently, my idea would be to list the table multiple times: For vanilla Doom/Heretic maps, coop and deathmatch are identical since there's just a "multiplayer" flag. So we'd get two tables: single and multiplayer. For vanilla Hexen maps, there'd be five tables: cleric, fighter, mage, coop, and deathmatch. There are also things that are present in the map but never appear (because, for example, they don't have any skill flag). For exhaustiveness it might be interesting to also list all things that are present, regardless of settings, but I'm not sold on it. Another thing: scripted maps can make more things appear during the game, something that a simple analysis of the thing data in the map lumps doesn't cover. Knowing how scripted thing spawning can be conditional and repeated, how do you express that? Sometimes, the spawning will always happen as part of normal gameplay, and it will happen just once, so it could be considered like a thing that was here from the start. Other time, it's optional (spawning some monsters to punish the player for getting a puzzle wrong for example) and it can be repeated infinitely, so the scripted thing count would be from 0 to ∞.
 * 1) Skill setting (usually 12/3/45, but in UDMF it can be 1/2/3/4/5, and ZDoom allows up to 16 skill filters)
 * 2) Game mode (single-player, cooperative, deathmatch)
 * 3) Player class present in game (usually just one in Doom/Heretic/Strife, but Hexen has cleric, fighter, mage, and in UDMF ZDoom allows up to 16 class filters)
 * 1) Single player (one table per class when multiple classes exist and filter things differently)
 * 2) Coop (for class-filtered things, assume all player classes are present)
 * 3) Deathmatch (idem)

Anyway, I welcome any better idea on how to organize this data visually. The current approach is good enough for Doom/Heretic/Strife single player but cannot handle Hexen, and for some ZDoom maps such as ZDCMP2 a non-standard table had to be used. --Gez (talk) 09:32, 2 May 2016 (CDT)


 * Heretic IWAD's tables already are already more comprehensive than Doom ones (with players starts, decorations, etc), but include just one extra column for multiplayer rather than a separate table. Would that same approach work for Doom? I don't see any Hexen IWAD map pages with a Things table, so that seems to be new territory.
 * My main question is what purpose do the tables serve, what would the audience get out of them by making them more comprehensive, or even list all things regardless of function? I personally wouldn't be interested to see that a level includes 16 lamps and 9 puddles of blood. For Doom tables, barrels used to be included but were later dropped. Maybe the reasoning behind that change (if anyone can find it – this is the closest I could find) also helps us decide on whether to include other things not in the current template.
 * You've outlined a complex problem which I don't think can be solved with a single solution, so breaking it up into manageable chunks may be a way forward. Defining the desired tables for the two vanilla categories above seems a good start. --Xymph (talk) 16:39, 4 May 2016 (CDT)


 * No specific layout to propose, but I'm glad this is being discussed &mdash; a standard form would look more polished, and help infrequent editors see what's missing. A few thoughts:
 * Most (all?) stock maps lack skill settings for multiplayer things, but it sounds like Gez wants to handle the general case of artisianal modding. It would reduce clutter if the display were flexible about this, e.g. parameters to collapse identical columns.
 * IIRC some contributors omit objects irrelevant to normal play: no difficulty flags (I've been listing these under Bugs only), in the void (should be bump-checked I suppose), or on unreachable surfaces (a non-algorithmic decision).
 * If this actually gets coded into SLADE, I'd suggest not laboring to implement the wikitext, because those details are vulnerable to rot. Just make it sufficiently generic, like delimited plain-text, that it could match most plausible markup with a few find-and-replaces.
 * Xymph may be giving us too much credit again. :>   Barrels were added sporadically over the years  with no discussion, so the "reasoning" was probably that some people like barrels.  (It happens .)  More broadly, there have been few changes in the table layouts and almost no talk threads, because stock maps are a sleepy neighborhood and actually extracting statistics has been tedious.  Definitely new territory.
 * Ryan W (talk) 22:44, 4 May 2016 (CDT)

Unindenting due to time elapsed. As mentioned above, manageable chunks seem the way forward to me, so I worked on the Doom & Heretic tables, and my tool DMMPST to generate them. Elaborate discussion of the many various aspects of those would overwhelm this here topic, so for that I created a blog user page. :) While extracting statistics may have been tedious, now it's a snap, but some degree of consensus needs to be reached before my approach can be rolled out wiki-wide. So I'd like to ask (prospective) participants in this topic, Gez in particular, to review my DMMPST page and the most recent table variants, provide me with feedback, and answer questions like these:


 * 1) are the two (vanilla multiplayer) or three (Boom-compatible) tables overall okay?
 * 2) the tables are spaced evenly within the available page body, so with just two tables they stay rather far apart - is that okay?
 * 3) are the choice of thing classes and the class order okay?
 * 4) are the items within each class and their ordering okay?
 * 5) in Heretic tables decorations, ambient sounds, etc are skipped, is that okay?
 * 6) should headers for empty classes (e.g. keys) be shown or skipped?
 * 7) should columns with identical values be merged via colspan?

If some point is not yet okay, how can it be improved? As offered before, participants in this topic can request a beta copy of DMMPST to help test and improve it. All my tools are derived from the ancient DEU codebase in C which covers only Doom and Heretic. While Hexen and Strife support look feasible and something I'll work on next, UDMF and ACS still seem bridges too far for me and I also feel it's impractical to try and support them in the same tool. Besides, I really fail to see the point of 16 skill levels and 16 classes. ;)

I realize this is just a start, and maybe an approach that's not as generic or groundbreaking as Gez aims for. The tables that DMMPST generates so far are essentially the same as the existing ones, only much more consistent. I don't have a "better idea on how to organize this data visually" either, and I doubt a single approach-to-rule-them-all exists. So until someone else comes up with a better idea, I'll continue down the path of multiple tables for the binary-WAD formats. --Xymph (talk) 12:38, 5 August 2016 (CDT)


 * My own answers:
 * 2. I'll experiment with the |width parameter to.
 * 3. Yes, though I kind of like the separate Health and Armor class in Plasmaplant too.
 * 6. Skipped.
 * 7. Probably not, the values jumping left and right depending on where the column dividers are make the tables fidgety (see Plasmaplant and ZDCMP2 above), though repeating the values would make them more crowded. Hmm.
 * And Yes to the others. --Xymph (talk) 13:23, 5 August 2016 (CDT)


 * Mine, then.
 * Guess so.
 * It'd probably look better if they were side by side rather than far apart.
 * Mostly.
 * Can be fine-tuned a bit for some things, e.g. backpack vs bag of holding, as I mentioned previously on the DMMPST talk page.
 * I think it's better to err on the side of including things than on not including them.
 * Better to skip them.
 * I'm not really fond of that, except when it affects the entire row.
 * --Gez (talk) 08:05, 15 August 2016 (CDT)


 * Since my previous post in this topic, plenty of progress has been made on DMMPST which can be followed on my user page from here. In response to Gez:
 * I'll take that as a 'yes'. :)
 * Agreed, hence the width=33% on the first table. Are the DoomII and Heretic sample pages now OK in this respect?
 * What changes in ordering do you propose? Refer to the overview page; I'd like to finalize this aspect.
 * Again see the overview page, and propose specific changes please. It's not yet clear how backpack/BoH should be classified and ordered, for example.
 * I added Heretic's ambient sounds, that's fine – its list of supported Things was the shortest of all four games before that anyway. But I still don't see any value making the tables for all games longer by including decorations and player starts. Sometimes more isn't better, it's just more. ;)
 * Thanks.
 * Upon some tests (see the Plasmaplant sample page) I agree that combining three identical values into a row works well, in combination with centering the single cell values as well. What do you think?
 * New question: how should Hexen tables be presented: using tabs, or some other method?
 * As always, more feedback by others remains welcome. --Xymph (talk) 07:19, 16 August 2016 (CDT)


 * For what it's worth, I support every change you make to the stock level thing tables. I cannot help having a personal grief on this, but it's the wiki that matters, and it seems that the thing tables will become clearer and more consistent. --Jartapran (talk) 10:08, 17 August 2016 (CDT)


 * Thanks, I appreciate that. I understand the grief and have much respect for the huge amount of work you put into compiling the existing tables over the past years. But computers are better than humans at adding up and compiling tables, so the goal of my project is indeed to make them more complete and consistent, and much easier to generate. In that sense a tool, any tool, is merely long overdue. Your efforts have served the wiki well though, we all stand on the shoulders of those before us, and DMMPST certainly benefits from yours. :) --Xymph (talk) 03:18, 19 August 2016 (CDT)


 * Going back to my latest bulleted list, I'm taking the lack of Gez's feedback so far as 'OK' on #2, #5 and #7, while #3 and #4 made progress and are almost there as per the DMMPST discussion page. That leaves #8. Anyone... anyone... Gez? ;) --Xymph (talk) 10:36, 25 August 2016 (CDT)

Bot on the loose :)
After lots of work behind the scenes, dmmpstBot is now ready to roll, and update the Statistics sections of a lot of maps. As a test run, I let it do the first map of Doom, Doom II, Heretic, Hexen, Strife, and Sunlust. More about the bot on the DMMPST blog some other day, but meanwhile, if anyone has any last-minute feedback on Things table content or layout, speak now or forever hold your peace. ;) Well, all bot runs happen from a configuration file and are therefore easy to repeat after tweaks, but I'd prefer to avoid cluttering up all those pages' history with more bot edits than necessary.

New DOOM monsters
If I'm not mistaken, the Possessed and the Unwilling are the same monsters (please correct if wrong). Why is Unwilling page still up? Also, should other variants of the possessed be counted as different monsters, or be included in an overall article on "The Possessed" like Zombie? --SuperShotgunPenguin (talk) 15:45, 4 May 2016 (CDT)


 * This is clearly debunked by the GameSpot exclusive "15 Minutes of Hell" gameplay video, where a distinct codex entry is gained for monsters known as The Unwilling, who I will note no longer look anything like the The Possessed. It seems this name was swapped at some point between E3 and now to a monster which more closely resembles the "Naked zombie" from Doom 3 and occurs in abundance in Hell. However we are still going to wait for the release of the game to adjust this because clarification - canonical clarification, not uneducated guesswork - is needed. --Quasar (talk) 11:17, 5 May 2016 (CDT)


 * It is quite likely also that the possessed have numerous minor variants. Unless some of them prove to be outstandingly unique, we may indeed handle them on the same article as subtypes. Examples of distinction:

--Quasar (talk) 11:20, 5 May 2016 (CDT)
 * Fat zombie, Fat zombie with wrench: Not worthy of distinction by separate articles.
 * Flaming zombie: Acts and looks so totally different from other zombies, he got his own article.

Screenshot above the map: where?
The other day while making the Doom2 map update sweep, I noticed that four times a single screenshot was placed above the map, but in three different ways: MAP20, MAP30, MAP31 & MAP32. And now in the actively updated UAC Ultra series, there are yet two other placements: MAP01: Dig (UAC Ultra) and MAP02: UAC in Exile (UAC Ultra) (same for 03-11, except 10 which has its screenshot in the usual section). What is the guideline, and if there isn't one yet (I'm learning ;)), what should it become? --Xymph (talk) 08:36, 6 May 2016 (CDT)


 * There is no rule, but, most articles are encouraged to have a single prominent "article-top" image at upper right. Generally this image will be selected to represent the page itself, such as in the mobile frontend search bar, and when pages from this site are shared to social media outlets. For most map articles that ends up being the map, but you can probably see how a screenshot does establish the mise en scene of a level more effectively than a bland outline of its linedefs can. Usually the reason it doesn't happen on map articles is due to the pesky upper righthand corner navbox templates that compete for that space. I have no real suggestion and I don't necessarily believe that all articles have to be uniform in this respect. If the navbox is too long, for example, it will end up pushing the screenshot, and then the map in the walkthrough, down too far. So that's to be avoided as an aesthetic issue when it would be present. --Quasar (talk) 09:48, 6 May 2016 (CDT)


 * I agree that a top-right screenshot has its benefits. Their appearance is indeed complicated by the navbox, the view mode (PC/mobile), the dimensions of the window or device screen, and the order/size of the boxes. For UAC Ultra map01 on my PC, the navbox and screenshot appear in that order above each other along the right edge of the window. But for maps 02-09 & 11, the screenshot is first in the source code and is shown in the top-right corner. The navbox appears left of it instead of below, thus crushing the opening paragraph into a narrow column. That looks ugly to me, so I fixed those pages. --Xymph (talk) 09:57, 19 May 2016 (CDT)

Sticky wicket
The new Doom seems to follow an Every Word Capped convention inside the game itself. So far I've been following the style of this wiki instead. But one thing that's always bothered me is Spider Mastermind and now that it seems it might be returning, what will its article be named - Spider mastermind (Doom 2016) or Spider Mastermind (Doom 2016)? The one not chosen should be a redirect, naturally, but we're also discussing what the stylistic treatment of the name within articles should be. If it's supposed to be a creature of unique character with a special status, "Mastermind" may well prove to be its title and should thus be capitalized (I've always felt that it was meant to be as such anyway, but I lost that argument against the majority). Do we have to hold off until the full codex is revealed to make this decision effectively? --Quasar (talk) 09:48, 6 May 2016 (CDT)

(Brainstorming) Expansion of the wiki's mission, or a wiki network
Quasar has mentioned some frustration on IRC a few times about the lack of active wikis for Quake. There are multiple, with varying degrees of scope (whole series, or just a single game), and none with a strong community to maintain them. There are even examples of id games without even as much popularity of that (for example: Rage) with very little hope of an independent wiki to spring around them. I just started thinking today, that it might not be the worst idea for us to expand out. Two possible solutions to this might be:


 * Changing the current wiki's scope to be inclusive of all id games, and some decisions would need to be made about how far that scope goes. I've had a short debate with Quasar on IRC about whether all id Tech 4 games might be included, being as relatively uncommon outside of id as id Tech 1 was.  I believe everyone might agree that all the in-between engines were too popular to ever have the same focus (all Valve games, Call of Duty games, Ion Storm games, etc).  This option would probably entail a branding change so that Doom is no longer the primary focus (side benefit: better results on Google? It could also be worse).  It would even allow direct linking from topics such as all the engine articles.


 * A new network of inter-connected wikis, likely on MancuNET, where each game or series is maintained independently. This would allow the Doom Wiki to maintain the current branding, but we can still have a tight-knit community overseeing all the wikis, and still avoid the awkward link to id Tech 5 on Wikipedia when the Doom Wiki talks about id Tech 4 and 6.  Questions might arise about which wiki certain articles should belong to.  For example, would id Tech 4 be covered on the Doom Wiki, Quake Wiki, a meta-id-Tech Wiki, all/some of them?  There are good arguments for all these options.  We still would have branding issues: multiple Quake Wikis already exist in the wild.  Perhaps we could get a consensus to fold them into our network, and reuse existing content?

I realize this is a bit of pie-in-the-sky thinking, but I'm not convinced of them being bad ideas. A very large disadvantage is that our current community is heavily focused on Doom, but I do believe we have a good overlap for fans of id Software in general, and we might be able to make such a thing work. All positive, negative, and alternative opinions on this are appreciated! --Chungy (talk) 18:37, 13 May 2016 (CDT)


 * IF we were to go that direction in the future, and I think there are higher priority subprojects here that need to be taken care of first, then I'd be looking to do it in the wiki farm or network direction, and have a NIWA-style setup with a central superwiki and many sister wikis with specific areas of coverage. And as discussed on IRC, we would not be breaking up this one in any way - it would remain covering everything Doom, and everything on the id Tech 1 engine. --Quasar (talk) 11:22, 14 May 2016 (CDT)

Why blaster pistol, when the game doesn't refer to it as such?
I may be wrong here, but I have not found any case where the pistol has been referred to as blaster pistol in the new Doom, so why is the article titled Blaster pistol?

Thanks. --SuperShotgunPenguin (talk) 10:06, 14 May 2016 (CDT)


 * An editor added it with that name, and believe it or not I don't have the game yet! All my PCs and my laptop are too outdated to run it all, so I'm flying blind off what I can scrounge up from videos, forum posts, news articles, etc. If the official name is simply "pistol" then we can rename it to that, or else let me know what the official codex entry for the weapon is called and that's what we'll use. The existing title can remain as a redirect if enough people are likely to think it's called that because of its similarity to the Quake series weapons. --Quasar (talk) 11:20, 14 May 2016 (CDT)

Proposal: more general monster article-top disambiguator/navigational template
The above is an example of a proposed replacement for Doom 3 also in and Doom 3 remake. Please provide input on the idea. It will allow linking to any increasing amount of monster(s) in the future if more games appear, without being as verbose as the current templates would be if they were to be chained, stacked, or wordily extended to be able to include the new Doom. --Quasar (talk) 22:49, 14 May 2016 (CDT)


 * I agree to this and have thought about this myself. It is a lot easier for navigation but the current one may be more user friendly and is, I believe, a convention in wikis. --SuperShotgunPenguin (talk) 14:42, 15 May 2016 (CDT)


 * Rather than duplicating the monster name, what about only the name of the game? Eg: Other incarnations of this monster: Doom 3 • Doom (2016) --Chungy (talk) 19:07, 15 May 2016 (CDT)


 * I was trying to avoid losing a lot of links to the game articles but I suppose it's not a big deal. However, if we were going to do that, I'd actually just prefer to drop the description parameters and have something like this: Other incarnations of this monster: Imp (Doom 3) &bull; Imp (Doom 2016) - Now you can see both the monster name and the game it is for w/o repeated hyperlinks getting in the way. Note this won't always be strictly repetitive - the new arch-vile equivalent in Doom 2016 is called the Summoner (and was still called the Arch-vile as late as the beta). --Quasar (talk) 10:19, 16 May 2016 (CDT)


 * Makes sense. What about monsters (or things, more generally) that have the same name but aren't different incarnations of the same concept? E.g. the Heretic gargoyle is also sometimes called an imp, the stalker could refer to Hexen's swamp dwellers or Strife's spider drones, the bishop can be the Strife boss or the Hexen mook, etc. --Gez (talk) 11:45, 16 May 2016 (CDT)


 * That's a problem I didn't think about and thus didn't set out to solve. The template could be given an extra disambiguation parameter which would handle current cases where this matters (there will never be sequels to Heretic/Hexen/Strife with any likelihood, so there's nothing to link to for other "incarnations" of those creatures). But if it becomes necessary in the future to have two- or three-way disambiguation, this template can't possibly handle such cases. There would either have to be a different template, two templates, or the special-case text would have to be entered directly into the article. --Quasar (talk) 12:24, 16 May 2016 (CDT)


 * Heretic got a sequel and Hexen a sequel with an expansion, but all Quake (II)-engine based. Anyway, I found your initial template not very clear, the bullet doesn't provide enough separation between the groups of hyperlinks, but your latest simplified version looks clean. --Xymph (talk) 14:27, 16 May 2016 (CDT)


 * (Unindenting a bit) You're right, of course, but I meant ones we would have scope to cover here ;) For that to be the case they'd have to be based on id Tech 1, unless we changed our stance toward the existing ones. I'll go ahead and revise the template to adhere to the above suggestions and we can go from there. --Quasar (talk) 15:07, 16 May 2016 (CDT)

are Possessed Soldiers separate enemies from the Possessed or not.
I understand that as the game has just been released, it will take a while to update and create articles but one thing that was bothering me, and depressingly I have nothing else to worry about, is whether the various types of possessed enemies (possessed soldiers, guards etc.) should have their own links on the Doom (2016) monsters template, or be linked under a general article of "The Possessed" like the Zombies from Doom 3. the codex entries count them as different, but the Monsters section on the Doom (2016) article links them underneath. --SuperShotgunPenguin (talk) 14:31, 15 May 2016 (CDT)


 * It'd help me make my mind up if I could even find a comprehensive list of the subtypes anywhere and a description of their behaviors. The current vacuum of details on the games' monsters is pathetic. --Quasar (talk) 16:04, 15 May 2016 (CDT)


 * Seeing as this wiki is using the codex entries for naming like "Combat shotgun" over just "Shotgun" and "Pistol" over "Blaster pistol", I thing that we should follow this all the way and have each codex entry as a seperate type and have no subtypes, it would result in a lot of links on the Doom (2016) Monsters template but it would settle this issue. Any other ideas? --SuperShotgunPenguin (talk) 16:18, 16 May 2016 (CDT)


 * Just to clear this up, I know enough about the game now to see how different the various possessed subtypes are and I do agree they should have their own articles, as they're at least as different as the zombieman, shotgun guy, and chaingunner of the original series, or zombies vs zsecs vs commandos in Doom 3. They're not just minor variants like "possessed swinging a wrench" or "possessed with slightly different texturing," like most of the Doom 3 zombie subtypes were. --Quasar (talk) 18:36, 11 June 2016 (CDT)

Doom 2016 Screenshots!
I captured some screenshots last night from the new doom for doom wiki. They may be useful, may be not:

Hope this helps for article creations.

YouTube embedding change
YouTube is now requiring a minimum size of 480x270 for video embeds. If you ask me, it's a little bit large but, without it, the player now needlessly disables both the volume control and the time progress indicator. This is bad for the end user so having the larger videos will have to do for now. --Quasar (talk) 10:29, 21 May 2016 (CDT)

Idgames template zoo
I have deprecated ig2 and its umpteen aliases because they only allow linking by id, which is a practice we need to discontinue. These IDs are volatile; if a file is deleted from the database, it is not possible to figure out what file it was actually pointing to as that row will be physically removed from the Doomworld DB. There has been discussion in the past about the entire series of IDs being volatile in addition, such that if the DB had to be rebuilt from scratch in case of a disaster by scanning /idgames anew, the IDs would come out totally different, scrambling every single link to them in a debacle similar to what happened when AtomicGamer changed their file layout. Likewise, I have deprecated the argument to the suggested replacement idgames template. We need to re-evaluate the entire set of these idgames templates as there are, I feel, too many options. I never know which one(s) to use in any situation and always have to open them all up to find the correct one. --Quasar (talk) 16:04, 10 June 2016 (CDT)


 * Having experienced the same, I fully agree the zoo needs to be cleaned out. --Xymph (talk) 16:21, 10 June 2016 (CDT)

Doom canon storyline
OK, so I'm over obsessive with the canon of any fictional series, and no more so with Doom. Does this wiki define a canon story line and if so what is it. e.g. are Doom 3 and 2016 part of the same universe as the original games. If it does not have a canon storyline, then this wiki needs to make it obvious and clear that there is no canon, Thanks.


 * Our job is to objectively interpret the games as they present themselves and not to draw any unwarranted or unsupported conclusions or connections that are not widely considered to exist or to be obvious by community standards. It is unknown if Doom 3 and Doom 2016 have a canonical connection. There are only subtle hints in the latter game itself that there could be one, and these could have easily just been intended as easter eggs by the developers. Without "Word of God" from the devs on the issue, we must simply report the existence of those items and the possibilities of what they represent (ie., both viewpoints - that they may indicate a connection, or that they are there just "for fun" to remind the fans about the previous entries in the series). Unsupported speculation is regularly removed and reverted from articles here, and on the whole we maintain a particularly high encyclopedic standard for our content. Fan fiction is never acceptable beyond articles about notable fan fiction works written from a real-world context. --Quasar (talk) 13:29, 18 July 2016 (CDT)


 * Is there any confirmed canon?


 * Not beyond individual sub-series. Ie., amongst official products, Doom II follows Ultimate Doom (with some retcons involved), and No Rest for the Living, Final Doom, and Doom 64 follow Doom II (in what order or combination they are co-canonical is unspecified and unknown). Doom II RPG makes references to some other games in the series, and also to Wolfenstein RPG, but I am not terribly familiar with it so I cannot speak about them in detail. In the Doom 3 timeline, Doom 3 happens first, at the same time as The Lost Mission and Doom Resurrection; Resurrection of Evil happens 2 years after it. There are again only easter egg like references to the original series at best in Doom 3, such as the appearance of the ancient civilization's hero resembling the original Doom marine (and therefore also bearing heavy resemblence to the artwork in Doom 2016 showing a similar hero fighting the same kind of demons yet again, but with his bare hands versus the Soul Cube). Beyond these sub-series, any firm connections are mostly conjectural. --Quasar (talk) 13:40, 18 July 2016 (CDT)

Thing data tables
While waiting for feedback on DMMPST development – as I am now, Gez and Quasar ;) – I've been updating and adding Thing data tables for items, weapons and monsters. Three details I'm wondering about:


 * 1) Monsters are normally shown with a Width attribute, e.g. Imp; the others with Radius, e.g. Backpack. Why the difference? It can lead to mixups, i.e. the Imp's projectile is listed with width 6, but that is actually the radius value and its width should be 12. The same goes for other monster's projectiles. I believe DeHackEd was used to attain the values, and that may be (part of) the source for the mixups, as the value 16 that it shows is indeed a radius, mislabeled as width. Confusion about that seems to be nearly as old as this wiki (first sentence). The game internally defines everything by radius. Wouldn't it be more clear and consistent if Thing tables all use the same attribute, and if so, which one?
 * 2) Monster tables include a Bits value in decimal and a list of bits composing that value, copied directly from DeHackEd. The source code calls these Flags, which I find a better description, especially since Heretic, Hexen and Strife have two sets of them. Also, the decimal value does nothing to help understand how the field is composed, using hex (8 digits with leading zeroes) would make those one or two fields much clearer. Are there objections against changing these two aspects?
 * 3) For weapons, how is "Shots per minute" determined?

Background: While working on the item and ammo tables, most of the data could fairly readily be obtained from the source code's info.c. For weapons and monsters the ZDoom wiki also proved most useful, but altogether the process became rather time-consuming and error-prone. Also, at first it wasn't clear to me how some values (such as monster speeds per second) were obtained, so I needed to dig deeper. Therefore, rather than using an indirect approach like DeHackEd's, I created a C program built together with info.c (and as many Doom .c and .h files as needed to make it compile) that directly extracts information from the mobjinfo, state, sprite and sound tables. I'm planning similar tools for Heretic, Hexen and Strife. The output is in plain text and not in wiki-table format as some attributes (like damage formulas) cannot be obtained this way, but that serves well enough to double-check (and correct, if needed) all Thing data tables in the long run. --Xymph (talk) 15:30, 29 August 2016 (CDT)


 * Vanilla Strife does not have two flag bitfields. Be sure you are not looking at the Strife: Veteran Edition source code, because we added a flags2 field in that port to support some new internal features we needed. Chocolate Strife is the appropriate point of reference. --Quasar (talk) 13:41, 1 September 2016 (CDT)


 * Thanks for the heads-up. I went for the latest-version approach, but reverted to the chocolate codebase now. For the other three games I'm using the original, vanilla codebases.
 * Given that this is your only feedback, I'll take it that you're okay with whatever the outcome of #1 above (I'm choosing Radius), and with "no" to #2. --Xymph (talk) 15:46, 1 September 2016 (CDT)


 * I didn't really have time to review the whole thing earlier to be honest but, I think selecting radius is the best, yes, as those values are what you'll find in the code and can be double-checked by anybody at a glance w/o having to be doubled. The original logic behind decimal flags values is because of how DeHackEd displayed them, yes. I would rather have the value in both bases, honestly, if it's practical, but I'm not sure w/o seeing it in an expansion. --Quasar (talk) 16:46, 1 September 2016 (CDT)


 * I made the first data table edit based on the above choices, please check out its Flags representation. I put hex first because that makes sense there, but then this field uses the reverse order of the ID# field (where decimal makes sense to go first). Not really happy with that, my solution would be to just drop the Flags decimal value. Any other suggestions?
 * I also moved up Mass below the other physical characteristics – it probably was below the pain attributes only because DeHackEd ordered them that way. And reaction time needed its unit. --Xymph (talk) 07:38, 13 September 2016 (CDT)
 * Looking at it, I think "ID #" ought to be renamed to something more accurate, like "Editor number". Maybe it's just me but to me the ID would be the thing's order in the mobj class table (for which there are enum constants such as MT_CYBORG in the source code). Dehacked also refers to thing types by that same number (e.g. the lost soul in Dehacked is "Thing 116"). ID is just too generic and ambiguous, whereas "editor number" is clear that it's the value that matters in the editor. --Gez (talk) 08:01, 13 September 2016 (CDT)


 * Most other data tables use "Thing type" for that field, and this inconsistency and "ID #" being too vague have been bugging me too. Using "Thing type" for monsters would be practical – for avoid having to update the field name in all the item tables – but "Editor number" is indeed the most accurate name.
 * Regarding the hex/dec Flags, Jon suggested on IRC to use "some wizzy javascript" to allow users to toggle the Flags representation. I'm not fond of adding that kind of complexity for a relatively minor bit of info. While much of the complexity can probably be cornered into a template, some visual cue needs to be added to the field to show the user that the value can be toggled, and such that it looks good in all skins. Additionally, we already know from the maptabs template that such things are tricky to get working on mobile.
 * The only minor benefit I see in keeping decimal Flag values around at all is to allow users to compare them to DeHackEd's output, but that tool should never have used such an impractical representation in the first place, IMHO, and I see little reason to keep accommodating that. --Xymph (talk) 09:29, 16 September 2016 (CDT)
 * After further thought about that ID# field, "type" is also how it's called on the Thing page and in the mapthing_t structs in the source code. Together with the practical benefit of not having to edit-for-consistency most weapon/ammo/item tables, I think "Thing type" is good enough a description for monster tables too.--Xymph (talk) 07:20, 19 September 2016 (CDT)


 * #1: yes, go with radius. #2: hexadecimal is certainly more useful and should be prioritized. #3 I suppose it has to be extrapolated from the refire delay in tics between two shots with the weapon and knowing there are 2100 (35*60) tics in one minute. For example if you hold fire with the pistol, it shoots every 14 tics (first time 4 tics in the fire animation, then another ten tics before looping back to the beginning of the animation if you hold fire). 2100/14=150, and the pistol article says 150.0 shots per minute. QED. --Gez (talk) 18:43, 1 September 2016 (CDT)


 * Wow, another great idea. IIRC you should be able to get damage ranges by including the attack functions and P_Random (easy for me to say of course!).  Ambiguity arises only when damage is not completely calculated within one tic, e.g. a BFG hit.


 * Shots per minute was determined by manually stepping through attack sequences to count how many tics constituted a complete loop. Gez has described what we were aiming for, but there were cases when two editors obtained different results, so for all I know there is some interpretation involved.  I believed that monsters should have values also (including stochastically computed rates for attacks that don't loop, e.g. zombieman or mancubus), but that research remains incomplete.  HTH.    Ryan W (usually gone) 19:23, 1 September 2016 (CDT)
 * For monsters, it's a fool's errand, it's random and depends on far too many external factors (notably skill level and distance between monster and target) to be be easily and meaningfully translated into a rate of fire statistics. --Gez (talk) 06:06, 2 September 2016 (CDT)


 * Thanks for your inputs. I implemented Shots/Min calculations for Doom and Heretic, and for some weapons the attack cycle is a little more complex than the pistol. For starters, if the "fire" action function is called twice during the cycle – like for chainsaw and chaingun – the firing rate is doubled, which is logical. Also, it appears that the tics specified for the final attack state, which invokes the A_ReFire action function, are not included in the cycle. After coding on that assumption, my calculations return the same numbers as listed in the wiki for all Doom weapons. For Heretic, I got different numbers for some of the weapons until I realized that a refiring cycle starts at the weaponinfo's holdatkstate rather than atkstate.
 * As for including and invoking the attack functions themselves to collect even more information than just from the tables, that seems a big stretch due to the wide variety of activity undertaken in them and the number of other functions they invoke in turn, which would need to be stubbed somehow. And that still wouldn't allow determining damage formulas for weapons in a reasonably convenient manner (if at all). --Xymph (talk) 16:47, 5 September 2016 (CDT)
 * Yes, the tics specified for the state which calls A_Refire do not matter if you hold fire. Here's the thing about state functions -- they're called whenever the actor enters the state (so they're called at tic 0 of the state). This has an interesting corollary that if a state isn't entered, the function isn't called. This may seem obvious, but when actors are spawned, they're spawned directly into their spawn state, in other word, they do not enter it, so actors never perform the function of their spawn state when they are spawned. (If they later loop back to their spawn state for any reason, they'll run the action normally of course.)
 * Anyway, the A_Refire action is simple: if the player is holding fire, jump back to the Fire state. Otherwise, do nothing. So if the player is holding fire, the weapon immediately jumps back to the fire state, and the state calling A_Refire is exited instantly, lasting a total length of 0 tics. If the player isn't holding fire, the weapon doesn't do anything special and the state runs for its normal duration before being followed by the next state. This is true of all functions performing a state jump, including those added by MBF or ZDoom. --Gez (talk) 17:55, 5 September 2016 (CDT)


 * Thanks for further clarification. --Xymph (talk) 07:38, 13 September 2016 (CDT)

Unindenting for new sub-topic: The descriptions of Thing flags in the wiki, typically only listed for monsters, were probably taken from DeHackEd. But after comparing those to their enum names and comments in the source code, I sometimes found the original descriptions inaccurate, and came up with new/changed ones for my DMINFO & HTINFO tools (work on their Hexen and Strife siblings hasn't begun yet). Here are tables of the old and new descriptions – when making my next update/addition sweep over all thing data tables, I intend to use the latter. Feedback on the choice of words, upper/lowercasing, etc. before that happens is welcome. --Xymph (talk) 07:20, 19 September 2016 (CDT)