Doom Wiki:Central Processing/2013

__NEWSECTIONLINK__

Archived discussions

 * 2005
 * 2006
 * 2007
 * 2008
 * 2009
 * 2010

FPShax/doom WTF?
What is this page - FPShax/doom - about? A dead website, which isn't even to be found anywhere in the internet archives. The page ist included in various categories, to which it not belong. To be honest, i would like to call a vote for deletion.--Cybdmn 21:56, 6 September 2011 (UTC)
 * Looks deletable to me. GhostlyDeath 04:04, 8 September 2011 (UTC)
 * To me too. --Gez 10:34, 28 September 2011 (UTC)

Need to answer a "captcha" question for links?
Special:Preferences tells me that I'm in the "Autoconfirmed users" group, however I still needed to answer a question (which replaces captchas here) to modify an external link. ???


 * Hmmm. Try logging out, dumping all cookies for doomwiki.org, then logging in again?


 * Possibly external links are purposely harder to use, now that we don't have Wikia's battalion of anti-spam tools.   Ryan W 22:46, 7 September 2011 (UTC)


 * I'd like to know if it's temporary until the wiki is properly configured. On other wikis (I think) autoconfirmed users don't have to solve a captcha every time they add a link. PolicyNonsense 10:47, 8 September 2011 (UTC)

The brave new world of independent hosting
Hello all.

Sorry to be the bug in the raspberry here, but our separation from Wikia has given us a few extra to-do items (mostly for admins). Ideas I've had so far:


 * Real-world issues
 * Designate one or more users who know how to contact the server maintainers offline, in case of a prolonged outage where they are unreachable in the normal manner. (I have nothing against Manc and I respect the longevity of his contributions to the community, but he is a human being like everyone else.)
 * Offsite backups. Even downloading the MediaWiki dump once a week is better than nothing .  I've just learned how to back it up myself, using this.    Ryan W 23:09, 22 September 2011 (UTC)
 * Review licensing notices to make sure our wiki-to-wiki copying practices are still justified, in the absence of standing Wikia directives. (Not a discussion about whether CC-XYZ or GFDL is better &mdash; that's for later.)


 * Vandalism, spam, and all that
 * Identify at least one admin who can perform range blocks competently, and knows how to deal with collateral damage.
 * Be vigilant about keeping Doom Wiki:Administrators accurate and up to date. In particular, we should try not to run out of active admins &mdash; we will be responding to attacks far more often, and without the automated reversion tools that Wikia's janitors use.
 * Consider reinstating Special:ProblemReports. Requires the ProblemReports extension which is no longer supported.  The server admins have had more than enough trouble configuring extensions that are *supposed* to be compatible, so I assume this is off the table.  It wasn't used much anyway, and it's easy enough to post a question on a talk page.    Ryan W 17:25, 18 September 2011 (UTC)
 * Consider semi-protection of Entryway (by far the most frequent target of junk edits). Two months after the relaunch, and no vandalism on Entryway.  Consider the subject dropped for a while.    Ryan W 23:31, 5 November 2011 (UTC)


 * Bureaucratic mop-up
 * Create Doom Wiki:Departure from Wikia (or whatever) to explain the reasons for the fork. This should include instructions for migrating an account, resetting preferences, etc.  IMHO it should also advise editors not to spam the old site or otherwise create fanfare.  OK, I made a stab at this.  If you were involved in the migration, I would love it if you fact-checked.    Ryan W 11:38, 20 September 2011 (UTC)
 * Remove links/references to Wikia from Entryway (including the transcluded parts), templates, and policy pages. Already done during "power user" cleanup period.
 * Deactivate mirrors of Wikia's help pages. (As a short-term fix, Wikipedia's tutorials are probably OK to link.)  Already resolved during "power user" cleanup period.
 * Remove references to Wikia policies/help pages from system messages. Already done during "power user" cleanup period.
 * Disable hardcoded shortcuts like  colon bug.) Already resolved during "power user" cleanup period.'''
 * Change the default skin!  :D  Already done during "power user" cleanup period.


 * Other
 * Possibly reach out, off-wiki, to inactive longtime contributors and notify them of the fork. (Even active editors do not always read Central Processing or dwforums.)  See reply to Janizdreg below.    Ryan W 02:56, 24 September 2011 (UTC)
 * Set up a widget allowing users to donate toward hosting costs. Done by Manc shortly after the site opened; Monobook users have to switch skins to see it.
 * Fix the robo-generated meta keywords and other SEO "enhancements" made by Wikia over the last 4 years. Meta keywords were apparently removed during the migration, page title has been changed, and major sites (other than Wikipedia) basically link here now.  IMO this is no longer a front-burner issue.    Ryan W 18:30, 18 September 2011 (UTC)

I regret the appearance of volunteering other people's time, but I cannot do all of these things myself as I lack the required technical skills. Hopefully the first two lists, at least, are non-controversial and people can agree they are needed.

Ryan W 02:46, 8 September 2011 (UTC)


 * The old wiki is still edited. What about copying revisions made after fork (if the article wasn't edited here)? Admins have a better way to do this (Special:Import), which preserves edit history without having to do too much work. I don't know how important it is to preserve the edit history, though.
 * An example: the Game Boy Advance article is edited there. Maybe the editor is unaware of the existence of DW forums (console ports is a niche topic). The editor is an unregistered user, which makes it impossible to contact him other than by posting to his talk page. Should we notify him of the new wiki? If yes, edits made already should be copied here. PolicyNonsense 11:30, 14 September 2011 (UTC)


 * I made a new topic below for import suggestions.


 * I would say people still editing the Wikia wiki should be notified of the fork where possible, as spreading awareness of it on the grassroots level is an important part of the migration process. The person in question has also contributed plenty of valuable information and should be among the very first to be invited over. Especially considering the fact that his/her IP address could change at any moment and he/she might very well eventually get frustrated with Wikia like we did. -- Janizdreg 20:55, 18 September 2011 (UTC)


 * spreading awareness . . . on the grassroots level  I took it upon myself to reach out to 6 departed regulars: Illdo, Insertwackynamehere, Kyano, Shidou, Splarka, Zaximus.  This is a completely subjective list and I have probably forgotten somebody.  As far as I know, everybody left on good terms.  As a rule, admins are/have been highly active elsewhere in the Doom community (I am the exception), so if Quasar can't find the missing ones, I sure won't.    Ryan W 02:56, 24 September 2011 (UTC)
 * Glancing over the user list at the old wiki (the one here is near useless) I found some others that might be worth getting a hold of: Doomknocker, Ashley Pomeroy, Mithran Denizen, Mega Sean 45 and Ixfd64. All seem to have a good amount of constructive edits (glanced over their edit history) and have visited the old wiki in the past month. Nuxius 09:12, 24 September 2011 (UTC)

Google rank
I don't know if you have noticed, but our Google rank has recently plummeted. When searching for "doom wiki", the first four results are from wikia, then there's three from Wikipedia, then some Japanese site, then the Chocolate Doom wiki, and the first result for this wiki is the multiplayer page... Last year, when I checked, we arrived instead of that Japanese site just between Wikipedia and Choco, and there was only three results from Wikia. Our Entryway doesn't appear in the list; while it previously did. Anyone has an explanation for why this is happening? We shouldn't become less relevant than earlier... Looking up some other wikis that I remember migrated away from wikia, they're all either in first position (tfwiki, wowwiki) or second position (grand theft wiki). Something has to be done I think. I just don't know what. --Gez 21:24, 19 January 2012 (UTC)


 * What you're getting in your results aren't mirrored in my results at all. GrandTheftWiki appears behind 3 GTA Wikia links and 3 Wikipedia links on GTA; Wowpedia appears behind 5 WOW Wikia links and 3 Wikipedia links on WOW. Looking at the various wikis on Wikia's pagerank (including the Doom Wiki on Wikia), I've noticed they have moved up to a PG of 5 (from 4). So it appears Wikia has moved up, more so than anything else moving down.


 * Your Doom Wiki results don't really match mine either, with the first doomwiki.org link coming in behind 2 Doom Wikia links, 3 Wikipedia links on Doom, and Chocolate Doom's Wiki. (that Japanese website is on down the page a bit)


 * So out of this, the only thing that really brings up any concern for me is that the front page isn't showing up, with the Multiplayer article coming up first as it did in your results.


 * I know exactly why this is happening, as well. However, it's a bit of a multilayered problem, so you'll have to follow me for a bit here, as it gets a bit confusing.


 * First off, do a search for "Doom Wiki". Now note that DoomWiki.org's first result is the Multiplayer article, with the front page not showing up. Now, use the links at the bottom to go to the last page of Google's search results. Here, at the bottom of the last page Google gives the usual line of "In order to show you the most relevant results, we have omitted some entries very similar to the 173 already displayed. If you like, you can repeat the search with the omitted results included." Click that link. Now you will be back on the first page of results. Now scroll down. Notice something showing up that wasn't there before? Yep, it's the front page, which Google has flagged as a duplicate (or extremely similar to another result). Why? Well, unfortunately, the answer is two fold.


 * First, let's start with the easier to solve problem. This has to do with how Quasar has the various different domain names set up. Unfortunately, instead of just forwarding doomwiki.net and doomwiki.info to doomwiki.org (which is the proper way to handle multiple domains for one website) he mapped them all directly to the website. So you can use this website from any of those 3 domains, complete with 3 different logged in accounts if you wanted, because as far as anything outside of the server (ie your browser) is concerned, it is 3 different websites. And this includes Google. However, they're 3 "different" websites with the exact same content (obviously, since it's the same pages on the same server). In other words, duplicates, and of course as we have seen previously, Google has a method of removing duplicates from its results.


 * Another coincidence of this is that it temporarily spreads results across all three domains, so some will be from the .org one, while others will be from the .net or .info ones. It basically makes this wiki competition with itself.


 * And this leads us to another, in this case particularly damning, coincidence, in that having multiple domains mapped to one website is something unscrupulous websites used to do to grab more visitors (ie create one crappy scam website, then get a bunch of different domains with celebrities names in them and map them to that one website, that way you show up in numerous search results and get more visitors). I say "used to" because Google caught wind of this and now has it set up to actively punish websites that do this in their listings. So over time, more and more links to this wiki will disappear from the results as Google's automated processes weeds them out.


 * That's why if you have multiple domains, you just forward the others to the one you want to use. Google then will completely ignore the other domains, doomwiki.net and doomwiki.info in this case (that's their combat against unscrupulous sites using that tactic). However, unlike the current method Quasar is using, it doesn't affect the actual main website, doomwiki.org in this case, at all (which is what we want).


 * Still with me? (heh, I hope so) Remember when I said this problem was two fold? Well, now we come to the other problem. (however, I have a solution for this one as well) This image will describe our problem, and the solution, better than I could.


 * So as you can see, unlike the WOW and GTA Wiki's, we are pretty much a carbon copy of the Wikia Doom Wiki, which is obviously a bad thing. However, that image also contains our solution. Change the Wikia wiki to better match up with all the other Wikia wikis. In other words, "Wikia it up", as I like to say it. Add a background image; use images to link to the Doom, Ultimate Doom, Doom II, etc, articles instead of text and the like. Remove some of the links that most people wouldn't need, simplify it.


 * This is something that would be good for Wikia, since designing pages for people with ADD and little children is what they want, and it helps us as it makes their page different from ours. Everyone wins. - Nuxius 10:42, 23 January 2012 (UTC)

Related discussion going on too. -- Janizdreg 14:16, 28 January 2012 (UTC)

Derivative works on the iPhone
There are some games, using the Doom Classic soure, which are not covered here, or just mentioned an a side note. The question is, how do we handle this stuff? There ist Hacx Classic, which is mentioned in Hacx. Hell On Earth and Doomsday are mentioned in Freedoom without names. Doomsday II: Legions of Hell and Dooms Knight, are not covered, both use Freedoom ressources, but with new maps. Bastards, the game using various ressources from community projects, as mantioned here, is not covered.

So how should we cover all these stuff? Just add new entries for the missing games, and improve the others in the sections, where they are mentioned? Or add new entries for those games too, and redirect to the main articles, where they are mentioned? --Cybdmn 08:03, 8 September 2011 (UTC)

FlaggedRevs Issues Thread
Now that doomwiki.org has launched, can we please discuss details/bugs/changes here, and not on dwforums or IRC? That would be awesome.

I'll start:

Who can be a reviewer
The wankery about contribution history, mostly due to me on the dwforums thread, applies only to complete newbies. I propose that people with established reputations in the Doom community can be granted the "reviewer" permission based on that, no matter what their edit count. (Not "editor" status though &mdash; that should always be case by case.) Such people should contact User:Quasar to get started. Ryan W 15:16, 11 September 2011 (UTC)


 * Update: apparently I have been misreading the MediaWiki documentation, and the Editor status is supposed to be granted more often than the Reviewer status. See the introductory section here.  This raises a few new technical questions, especially about auto-assigning permissions.  This subsection ought to be titled "Who can be an Editor".    Ryan W 03:11, 28 September 2011 (UTC)

Backlog
All pages (main, redirects, File: and Template: spaces) are marked as unchecked by default. This may take a while. Volunteers are welcome! Ryan W 15:16, 11 September 2011 (UTC)


 * Update: I estimate that I have just reviewed 40% of the mainspace backlog (articles plus redirects). If the other reviewers together can't manage 60%, then we have issues.  :>     Ryan W 02:54, 17 September 2011 (UTC)
 * I'll go ahead and volunteer to help with this. (I have some free time) Hopefully I've been here long enough to be entrusted with Editor status (LOL). Nuxius 03:18, 22 September 2011 (UTC)

Another backlog is forming from the previously reviewed but edited since pages. IMO this should get more attention, as anonymous visitors are shown reviewed vesion by default. (Some pages have edits pending for nearly a month.) I think that the pending changes should be either reviewed or reverted. —The preceding unsigned comment was added by PolicyNonsense (talk • contribs) 08:32, 14 October 2011.
 * Something that would help would be if some people (e.g. admins, reviewers, editors, etc.) were granted the authorization that makes their edits reviewed and checked automatically. I see little red exclamation marks next to my edits in the recent history. And I can make them disappear by reviewing my own edits. Which is silly. And since I generally don't bother doing so because, well, it is silly, the result is more backlog for the backlog god. --Gez 18:19, 14 October 2011 (UTC)


 * The exclamation points are for patrolling, not reviewing. Two different things.  According to this, admins and Editors should already be able to mark patrolled, and autoconfirmed users should already be autopatrolled.  Maybe Quasar/Manc just switched patrolling off during the migration (since we already had FlaggedRevs).


 * More people should definitely, definitely be given the review ability. But Manc has said he doesn't want to change any settings whatsoever until the server load issues are fixed.  :(     Ryan W 20:15, 14 October 2011 (UTC)


 * Bump. Can someone please review new changes to checked articles? PolicyNonsense 18:19, 1 January 2012 (UTC)

"Under review" flag
After the backlog is clear, I hope Special:Unreviewedpages will become useful. Note that if it says "under review" next to an article, it probably means someone looked at the draft and decided it was crap, not that they still have the page open and are mulling it over. EDIT: actually it does go away, but only after 10 minutes or so. Ryan W 15:16, 11 September 2011 (UTC)


 * There also needs to be a page created for Help:Page_validation, as this red link appears on just about every article on the wiki now. - DooMAD 16:04, 13 September 2011 (UTC)


 * Shit, I didn't realize that was happening already. I'll do some work on the Help: space next time I'm at home.    Ryan W 16:41, 13 September 2011 (UTC)


 * Should Reviewers have access to Special:Unreviewedpages? At the moment it appears to be locked for Editors only. - DooMAD 19:46, 18 September 2011 (UTC)


 * That's a really good idea. Quasar and I are trying to figure out how to change it.    Ryan W 11:26, 20 September 2011 (UTC)


 * As you may have noticed, there has been a delay. :Z   Here's a trick I just discovered for finding draft edits: look at Special:Contributions for someone with a lot of edits, extending the limit to 500 (or 5000 perhaps).  Unreviewed revisions are highlighted.    Ryan W 04:47, 29 September 2011 (UTC)

Review quality
I'd like to know why the only levels I can get are Unapproved/Sighted (for Accuracy), Unapproved/Basic/Moderate (for Depth) and Unapproved/Acceptable/Good/Concise (for Readability). Among other things, this means that the higher levels listed by the (Accurate/Well sourced/Featured; High/Featured; and Featured, respectively) aren't available. If a page decides that it is at a higher level than what is available for review, then approving is impossible or ineffective. Any changes remain on the draft forever. That means I have to edit the page's stability to lower it. It's weird. I think it's because I'm not a reviewer. I think all admins should have reviewer rights because it doesn't really make much sense for them not to. --Gez 12:10, 7 February 2012 (UTC)

Create a whitelist of 'good' sites which can be linked to without captchas
I propose to add some sites to the whitelist of sites which can be linked to without solving a captcha, and to add at least the following sites to it: Ryan W seems to suggest that it's preferable to be a coder to add entries, but this whitelist suggests otherwise.
 * doomworld.com - there's a lot of links to idgames database and forum
 * zdoom.org
 * doomedsda.us
 * Probably would be better to encourage users to use the templates, such as the DW forums template and the idgames template to link to the doomworld forums and idgames database, respectively, without having to solve a captcha. It should be possible to create ones for the ZDoom wiki, forums and the doomedsda demo database as well. Nuxius 07:17, 14 September 2011 (UTC)
 * Nope. It doesn't matter if you use the template - you have to solve captcha all the same. PolicyNonsense 07:26, 14 September 2011 (UTC)
 * Ah I see that you're testing templates. I'm sure that I had to solve the captcha when adding a link to Phobos: Anomaly Reborn article. I just tried editing your sandbox page to add a link - captcha appeared. Maybe you are free to add any links? Can you try? PolicyNonsense 07:35, 14 September 2011 (UTC)
 * Hmm, that's interesting, as I did not when I tested it. Perhaps I have a higher level of group rights here than I thought I did. To be honest, the way the whole Group Rights list is set up here makes it a bit of a confusing mess. Too much redundancy along with some rather odd "right" organization.
 * Anyway, in that case, then yeah, I would agree that we need a whitelist. Nuxius 07:44, 14 September 2011 (UTC)
 * Ahh, I see while I was making my post, you figured that out as well. Nuxius 07:46, 14 September 2011 (UTC)
 * Nuxius, I totally agree about the redundancy. (Happened because there was no overall plan; individual MediaWiki developers added new flags one at a time.)
 * PolicyNonsense, there may well be an exception for edits in your own userspace. But I do see one definite problem: new accounts are not being assigned the "doomer" group by default as was intended.
 * AFAIK only the database admins (Quasar, Manc) can change such group rights.   Ryan W 19:00, 14 September 2011 (UTC)
 * Apparently any admin can do it. :p --Gez 19:00, 21 September 2011 (UTC)
 * Any admin can edit the page, but knowing regexps is not a requirement for adminship. If everyone knows them but me, good; it should be no problem to keep the list updated.  It is however misleading to say any admin can do it, especially as we acquire new admins.
 * In this case, at least one important refinement is needed: . A lot of my email spam used to look like that.  If I had created the page immediately, I probably would have missed it too.    Ryan W 19:17, 21 September 2011 (UTC)

Leftover links to wikia.com
These articles still link to Wikia sites, but I'm not sure how best to replace them (or whether replacement is even a good idea): Ryan W 18:40, 17 September 2011 (UTC)
 * Chex Quest Wiki: Chex Quest Wiki
 * Mega Man 8-Bit Deathmatch Mega Man 8-Bit Deathmatch Wiki
 * Vagary: Quake Wiki
 * Wiki: SLADE Wiki
 * Wolfenstein SS: Wolfenstein Wiki


 * Quake too, although I suspect these links may have to remain. If the most accurate and up to date resource for any given subject happens to be hosted on Wikia, we can't really expect to mirror everything and have it on this wiki unless we vastly expand our scope.  While we have a basic summary of other games like Quake, due to their connection with Doom, we're probably never going to include anything as comprehensive as an entire wiki dedicated to that subject.  - DooMAD 10:44, 18 September 2011 (UTC)


 * Sure. I brought it up in case people know of any good non-Wikia resources.  (For Slade and MM8BDM, few options I suppose.)    Ryan W 16:19, 18 September 2011 (UTC)


 * The suggested rule against linking to The Site Which Shall Not Be Named was meant, in my case anyway, to mean the Doom Wiki as it is still hosted there, and not to other wiki resources. I would strong urge and prefer the use of alternate resources where they exist obviously, but we should not butcher articles just to get rid of these other-wiki links in the meantime. -Quasar 18:06, 20 September 2011 (UTC)


 * Timeline: Another one with a wikia link. I guess there's historical reasons to leave it be, though. --Gez 19:44, 21 September 2011 (UTC)

Other community wikis
Took it one step further and purged the ZDoom wiki of about 50 links (mostly via templates) to the old site, heh. - DooMAD 22:30, 18 September 2011 (UTC)
 * Thanks for that. I was planning to do it as soon as the wiki would officially open; however the wiki decided to open while I was without Internet. ;) Also changed the link on the frontpage of the SLADE wiki; even though that one is itself on wikia. --Gez 18:36, 21 September 2011 (UTC)

List of content to import
If you spot content worth importing over from Wikia, please list such things under this header. This way the admins have a handy list to refer to for doing clean imports with preserved edit histories, which regular users cannot do.


 * Uh, Special:Import works by page title not by editor.   Ryan W 21:36, 18 September 2011 (UTC)
 * You can always check their edit history though. Listing just this user's account instead of every page they have edited helps keep this list less cluttered. Nuxius 07:28, 21 September 2011 (UTC)


 * I would say all edits by the user 108.13.114.253 are useful and should be imported here. -- Janizdreg 20:55, 18 September 2011 (UTC)

Game Boy Advance, I guess.

Genealogy
Before I make any further edits along this road; I noticed that the genealogy boxes on many port pages include "Strife" as a predecessor. AFAIK, the Strife source code is lost and all Strife-supporting engines have re-implemented it. I think it is misleading to include strife as a predecessor in a genealogy chart for this reason and it should be omitted. Similarly, an explanation should be added to Category:Strife ports. Thoughts? Jmtd 12:54, 20 September 2011 (UTC)


 * Disagree in the cases of ZDoom, SvStrife, and in particular, Chocolate Strife. All three derived their Strife support from direct reverse engineering. For the latter most, pain-staking effort was made to recreate the original style of the code as well as its behavior to the most exacting standards possible, to the point where demo compatibility has been attained. The Chocolate Strife source is, for all intents and purposes, the recovered original source code. The output of the IDA Pro disassembler is sufficiently like the original code in most cases to enable this claim IMO, even though many necessary translations were made after the decompilation. The only things inexorably lost are original function and variable names, and comments - though it is unlikely the code was well-commented in the first place. At the root of the issue is the definition of inheritance, and at no point have we said that inheritance necessarily requires source code in the first place. Binary code is another form of code that can be inherited from just as validly, IMO. -Quasar 17:56, 20 September 2011 (UTC)


 * I have reverted the change to the ZDoom article, mainly because it broke the formatting of the genealogy table, and because I'm not getting any response to my comment above -Quasar 16:35, 21 September 2011 (UTC)


 * I'd tend to side with Quasar here. --Gez 18:42, 21 September 2011 (UTC)
 * I agree with Quasar as well. Nuxius 03:14, 22 September 2011 (UTC)


 * Reverted the Vavoom article as well, then. --Gez 10:38, 28 September 2011 (UTC)

Configuration changes as of 2011-10-16
A few important configuration changes have been made as of October 16: --Quasar 16:51, 16 October 2011 (UTC)
 * Some breaking changes to the Monaco CSS have been repaired.
 * Extension Oversight has been removed and replaced by MediaWiki 1.16.x's built-in RevisionDelete functionality.
 * Extension UsabilityInitiative has been disabled completely. This may revert some modifications to the Vector skin, and has removed the buggy "enhanced" edit box which was causing serious issues with copy-and-paste, amongst other problems.
 * Improvements to FlaggedRevs configuration are under research and are, at the moment, not implemented yet, but will be rolling out shortly


 * At the risk of being rude, what is your FlaggedRevs idea? 2 months ago when I brought it up on IRC, you said you were almost done thinking it over, and would propose it on-wiki for discussion.    Ryan W 01:01, 24 December 2011 (UTC)


 * Bump again. If this gets to 3 months with no followup, I'm just going to start appointing people (and other admins can do the same or not).  FlaggedRevs isn't practical unless we are able to deal with the backlog.    Ryan W 06:10, 3 January 2012 (UTC)

Strange amounts of vertices in DOOM map articles
Hello! For map articles, there's a map info section which gives general statistics about the levels in question. I've noticed that the amounts of vertices for the stock maps are regularly higher than what some of the level editors give (DCK and Doom Builder, for instance). The amounts of things, linedefs, sidedefs and sectors, however, do match. For example, the maps in The Shores of Hell have the following information applying to vertices (first comes the current WIKI info and then DCK's / Doom Builder's):

E2M1: 371 (327), E2M2: 1.352 (1.352), E2M3: 874 (810), E2M4: 1.054 (909), E2M5: 1.235 (1.109), E2M6: 967 (886), E2M7: 1.626 (1.451), E2M8: 216 (186), E2M9: 160 (150)

The DCK information in parentheses is from the maps of Ultimate Doom v 1.9. All of the previous figures that currently are found in the articles were brought by user Cyb (the figures made their way into the article with the opening edits, long ago) with the exception of E2M2's figure that was changed to 1.352 by user Ryan W. http://doomwiki.org/w/index.php?title=E2M2:_Containment_Area_%28Doom%29&diff=next&oldid=37029 (Cyb's original figure for vertices was 1.537.)

I wonder if Cyb is still around so that he could comment on his source material (I really am new here, so I don't know any of you or the community history of this WIKI). Otherwise, given that the information is false, I may be permitted to change it to that of DCK's? I'd love to. :) Comments on this case? --Jartapran 01:32, 30 December 2011 (UTC)


 * Wow, thanks for examining these articles so carefully! Cyb hasn't edited since 2006 so I assume he's gone for good (his twitter feed looks current though).


 * In theory, we should not be relying on utilities that are never updated, because there is a greater risk of stumbling over a large bug. If anybody wants to fire up DB2 or DeePsea and run these again, I'll certainly endorse that.  Bonus points for counting them by hand in E2M9 just to make sure.  :D   I would do it myself but my virtual Win98 box just blew up.    Ryan W 03:30, 30 December 2011 (UTC)


 * Hey, Ryan! I ran Doom Builder 2 and counted by hand the vertices in E2M9 and E1M8. For the former, I received 150 vertices and for the latter 264 (went the process through twice, just to be sure). It reads in the article that Phobos Anomaly would have 328 vertices, a figure that once again is higher than it should be. The map in the article is absolutely identical to the 1.9. version I have. I really can't tell where the extra 60 vertices could reside. I've downloaded Pascal vd Heiden's Statistics Plugin for DB2 and received the following information about E1M8: Things: 126, Vertices: 264, Linedefs: 333, Sidedefs: 511 & Sectors: 74.


 * Then again, where could have Cyb got the vertex figures? He couldn't just have made them up from somewhere. In any case, it seems that the vertex information is incorrect at the moment whereas other data is as it should be. I'm not sure how you treat plugins (such as the one I linked to you) as providers of information but this one seems to work, at least for the Fortress and the Anomaly. If you're unable to use DB2 or DeepSea, I hope there could be some other user who would have an access to them. It would help to verify the content I've written. Could you, Ryan, still give your opinion about plugins for updated editors? --Jartapran 04:54, 30 December 2011 (UTC)


 * Sounds like you're making good progress. The only thing I can think of is that Cyb used the DOS package, but I can't believe 10+ maps were changed between releases (myk, are you here?).  I have never used DB2 so someone else should answer that, but in principle the counting procedure can be double-checked, since the source code is available...    Ryan W 06:48, 30 December 2011 (UTC)


 * The entire question is whether you're tallying the vertex count before or after node building, since whenever a pair of segs is created from a linedef, a vertex is added. Map editors silently delete vertices that aren't attached to a linedef, so when you open a map in a map editor, you don't see all the vertices created by the node builder. Note that the easiest way to count vertices on a map is to just look at the size of the VERTEXES lump and divide it by the size of a single vertex. This gives you the total, nodebuilder vertixes included. --Gez 10:58, 30 December 2011 (UTC)


 * Cyb's formula for the vertices, indeed, was Vertexes lump / 4 (E1M8: 1.312 / 4 = 328 & E2M9: 640 / 4 = 160). Went through test calculations in WinTex. Guess it's the best way to express the vertices of the maps so we'll let them be the way they are. Thanks for bringing that up, Gez. --Jartapran 13:57, 30 December 2011 (UTC)


 * Changed E2M2 aricle to use total vertex count for consistency (see Gez's comment above). PolicyNonsense 12:32, 30 December 2011 (UTC)


 * Attempted an explanation in the Vertex article, in case the issue resurfaces.   Ryan W 21:48, 30 December 2011 (UTC)


 * Nice work! Thanks, everyone. --Jartapran 22:55, 30 December 2011 (UTC)

Abuse Filter?
I'd like to suggest installing this extension. It has the ability to catch spambots in the act and preventing them from actually going through their edits. So instead of having to go delete pages or revert changes, there's pretty much nothing to do. Things like "anon IP creating user page" could be an auto-blocking rule, for example. --Gez 23:20, 2 February 2012 (UTC)


 * Pretty heavy artillery for us, but I suppose the problem will only get worse. If we created new filters only in response to events (not edits we think might happen someday), I'd support this.    Ryan W 02:03, 3 February 2012 (UTC)


 * I'll do some research into this. Some things we can do by changing permissions, though (see below). --Quasar 15:41, 8 February 2012 (UTC)

Permissions change suggestion
I would suggest that we remove permission to create new talk pages from anonymous users. They're already not allowed to create articles in other namespaces, and this exception is exploited by nonsense-spamming bots that probably blindly attack any HTML form and mean to place links in a field that isn't present/supported on wikis. This doesn't prevent editing existing talk pages. I think if someone wants to create an entirely new talk page, asking them to register first is not a huge deal. --Quasar 15:40, 8 February 2012 (UTC)


 * And so bots will create pages in the main namespace. In the talk namespace, it's only visible to a few editors. Plus, by that logic, needing to register before editing isn't a big deal either. Are you sure that this is what you want? PolicyNonsense 17:02, 8 February 2012 (UTC)


 * I agree with PolicyNonsense, and moreover, the newbies and IPs willing to *use* talk pages are the ones we want to keep.   Ryan W 17:43, 8 February 2012 (UTC)
 * Blocking talk pages to anon IPs doesn't seem really relevant. Blocking user pages, however? Yeah. There's plenty of bots who create both WhateverRandomName and User:WhateverRandomName. The latest example at the moment being this one, who made Morettic and User:Morettic to babble about the crisis of the € and the Greek debt. --Gez 18:01, 8 February 2012 (UTC)
 * I encountered the same bot, "Morettic" on the Legacy wiki. It registered an account to spam there, so limits to anonymous users will make no difference at all. - DooMAD 19:17, 8 February 2012 (UTC)


 * I guess you guys haven't noticed the pattern of attacks by bots that create new Talk pages filled with nonsense, but, OK. Bots can't register accounts here because of the strong captcha. If spam appears on an article that requires registration to edit or create, it's because a human did it. --Quasar 03:22, 9 February 2012 (UTC)


 * Yes, this is our highest-volume problem right now. It's just that, if we address it this way, we alienate a population known to produce good contributors.  I think that's a terrible trade-off, so I objected.


 * With AbuseFilter, we could (I think) prohibit actions such as:
 * Creating user talk page of a user with 0 non-talk edits
 * User page created by someone who isn't that user
 * Same user/IP creating multiple user talk pages five minutes apart
 * Same IP (or proximate IPs) editing multiple talk pages with identical edit summary


 * Ryan W 14:53, 9 February 2012 (UTC)