Doom Wiki:Central Processing/2015


Central Processing archives

Big fat list of Vfd[edit]

Ladies and gentlemen, I'm laying here a list of articles that are currently (as of today, I mean) in a VfD. I know there is a category but I'll just leave this here, along with the dates, which I think are important.

Also, these categories:

Also, these files:

I did not vote on most of them because I'm a horrible person, but you knew that already. --Kyano (talk) 21:21, 25 July 2014 (UTC)

About the Bruiser Demon case, my opinion three years later would be that maybe the policy ought to be rethought. I think there is some justification for having pages on individual resources when they are notable enough. Many custom monsters have become more-or-less standard staples (and I'm not talking just about custom ZDoom monsters here, DeHackEd wonderkids like the evil marines or the afrit are memorable and noteworthy) and I've seen them discussed casually in Doomworld threads that weren't specifically about them. And we do have individual articles for one specific kind of resource already (maps), so given the emergence of gameplay mods which do not have maps but do change monsters and weapons, it might be time to allow individual articles for other resources than maps. Just to be clear though, I think this should be reserved for memorable resources that have been used in several high-profile works and where the behavior has known little or no alteration between their various versions. So the Bruiser Demon (KDIZD, Stronghold, ZDCMP2...) would qualify, but the upside-down orange caco from Zen Dynamics (and AFAIK no other mod) wouldn't. --Gez (talk) 13:32, 28 July 2014 (UTC)
I agree for the most part, but it's important IMO that we very strongly distinguish between these resource monsters and the original ones. For example, having them in their own category (not just Monsters, but maybe User-created monsters or some other suitable subcat). --Quasar (talk) 14:35, 28 July 2014 (UTC)
As a side note, the proposed speedy deletion criteria would only affect two of these, Doom23.gif and Ralphis.jpg (and the first might need to stay until the glitch gets fixed, can't remember).    Ryan W (talk) 23:16, 1 August 2014 (UTC)
I would oppose speedy delete of Doom23.gif for now; I've been using it to monitor the status of whether or not GIF thumbnailing has been fixed (this is a server-side backend issue which is due to the distro of Linux on MancuNET being too old...) --Quasar (talk) 17:03, 23 August 2014 (UTC)

Just to clarify things, I only nominated the redirect to the aquarius page, not the actual page. That was nominated by Grain of Salt. Justice ∞ (talk) 02:47, 20 February 2015 (UTC)


In the future, I suggest archiving not the previous year, but the one before. E.g., please don't archive 2015 in 2016; instead wait until 2017. Thanks. --Gez (talk) 10:45, 28 January 2015 (UTC)

I'm apt to agree except for how massive the article starts to get. I think last year has a record number of issues that should still be considered open and actionable. It's getting to the point where I might have to consider having something more effective for tracking them, like a Bugzilla instance somewhere for example. --Quasar (talk) 14:24, 28 January 2015 (UTC)

January 2015 upgrade[edit]

manc and I will be attempting to upgrade the wiki to MediaWiki 1.24.1 as of tomorrow, assuming all goes to plan. This time it seems that the only major question is the EmbedVideo plugin (as usual), so that's one thing that will need immediate verification after the upgrade. --Quasar (talk) 15:32, 28 January 2015 (UTC)

We are now up and running on MediaWiki 1.24.1 - a couple minor issues remain, and I'm still testing some stuff. Report anything you find here. --Quasar (talk) 03:56, 30 January 2015 (UTC)
It seems most of our extensions were not upgraded, so a number of them are currently broken. Currently known to not be working:
Special:CheckUser (if user has permission to use, throws an exception)
Special:Editcount (always throws an exception)
Will keep this list updated until the situation is resolved. --Quasar (talk) 20:08, 30 January 2015 (UTC)
I have updated all extensions except EmbedVideo. So far everything is working, but it's impossible to test that much stuff exhaustively. --SpiderMastermind (talk) 23:43, 30 January 2015 (UTC)

Group image VfD[edit]

Following up an IRC conversation, I have opened a deletion thread for 57 images recently added to Enter the Doom Chapter I: Lucido Attack and Enter the Doom Chapter 2: Legacy.  Please feel free to contribute your opinions here.    Ryan W (talk) 00:02, 3 February 2015 (UTC)

Strife minor characters[edit]

Please comment on or help advance the status of the three merger requests for Strife minor characters Ketrick, Sammis, and Ulaine. Of the existing articles, these are the only ones that I feel should be merged. All three are explained in Strife minor characters - Hub 1. --Quasar (talk) 19:22, 25 February 2015 (UTC)

I think the merge is a good idea. MacGuffin could be considered a minor character as well, but I guess he is unique enough for a separate article. --Jartapran (talk) 00:52, 26 February 2015 (UTC)
MacGuffin is borderline but there are SEO considerations for him if nothing else redeems him; we are linked to from at least tvtropes for our article on him. I think a big enough deal is made out of him, similarly to Worner, for him to have his own page. Sammis, while he does possess a plot-important key, is never referred to in the third person by anyone else (they all tell you to go to Ketrick instead, who is actually a red herring), and can be killed without ever talking to him in order to get the key. It's a gray zone but I prefer we keep most of the well-written, already pictured character articles. It's a small set that will never grow any larger. Speaking of pics, I will be adding some to the minor characters pages when I can get around to it. --Quasar (talk) 01:18, 26 February 2015 (UTC)
While Ketrik and Sammis have some minor plot relevance, Ulaine does not so this article at least should be a no-brainer. --Gez (talk) 08:13, 26 February 2015 (UTC)

Add autocheck to Jartapran[edit]

I think User:Jartapran is a good candidate to try out the "autochecked" group permission on, as he is already an editor and reviewer and has demonstrated universally high quality of editing and willingness to work together on various important projects. I've suggested he mull over requesting admin rights, but would like to try out that permission on him in the meanwhile. Put it to a vote here. --Quasar (talk) 22:15, 3 March 2015 (UTC)

No objection. --Gez (talk) 00:00, 4 March 2015 (UTC)
Jartapran pointed out that editors already have autocheck, so we determined that the missing permission was in fact autopatrol, which only admins currently had. I added autopatrol to the reviewers group, which currently includes Jartapran and DoomAD besides admins who are implicit members, since it seems logical enough. --Quasar (talk) 19:07, 4 March 2015 (UTC)
I was just about to suggest that when my computer started to appear compromised and I unplugged it.  :7   Good show.    Ryan W (talk) 22:15, 4 March 2015 (UTC)

Doom 64 maps[edit]

We now have nearly two full sets: old, new.  Which should we keep?  They seem to differ in color scheme and line weight.

(IMO this is no one's fault, just something that happens on wikis when a project is left half-finished for a long time.)    Ryan W (talk) 01:29, 9 May 2015 (UTC)

Vote keep both, because the old set have been marked up with walkthrough tags which are only useful when discussing the map in its own context. It's impossible to do comparative kind of stuff with images that have walkthrough tags on them. --Quasar (talk) 19:53, 1 June 2015 (CDT)
Point taken, since we already do this for the DOS series.  Let the first stone be cast by him whose to-do list is getting shorter.  :>     Ryan W (talk) 16:13, 2 June 2015 (CDT)
PS, I am mulling over some plans that might make it possible to toggle between the walkthrough markup images and the normal ones in-article, but it'd probably require some work in our Common.js, which is always fun. I'd be doing this for all the canonical map articles where both variants exist using some kind of template, provided I can make it work satisfactorily. I'll let you know when I start working on it (I'll be experimenting in a sandbox, needless to say). --Quasar (talk) 19:49, 2 June 2015 (CDT)
That sounds excellent!    Ryan W (talk) 20:05, 2 June 2015 (CDT)

Raven engine games[edit]

Given that we have an article for Shadowcaster, which was at the time made due to it being based on a transitional pre-Doom engine and with a lack of evidence that any other game was using that engine, should we have matching articles for CyClones and In Pursuit of Greed? Both of these games are fairly poorly documented on the net. The Wikipedia article for CyClones should have a stub notice on it, it's so bare. Linking to it is about as good as not doing so at all. --Quasar (talk) 19:52, 1 June 2015 (CDT)

AFAIK the CyClones engine is not based on the Raven engine, and was instead written in-house. Personally I have no objection to having more short articles about contemporary games but it would represent widening this wiki's scope. --Gez (talk) 06:53, 2 June 2015 (CDT)
Raven called it a "rewrite" but we've found evidence that it was not "complete." For example it still uses the same resource formats and archives. This means it's heavily related; watching any video of the game will also show that it still largely behaves the same, with some added flexibilities. As far as scope, the reason I think these fit is because the engine they're using is a direct predecessor of Doom - the earliest 0.2 alpha even contains some of the same source code file names in its binary, showing just how close the evolutionary relationship really is. --Quasar (talk) 19:45, 2 June 2015 (CDT)
The definition of a "rewrite" can be a bit ambiguous. I think it was Quake 3 or Doom 3 that was supposedly on a rewritten engine but there are still many similarities to previous engines (see AI code that traces back to catacomb). While that branch of the engine definitely has its own name and should be mentioned as such, for the purposes of this wiki I think it's safe to file them under the same article. (At least until someone bothers to do enough reverse engineering to technically explain the difference.)
On that note, perhaps instead of full articles we can just have articles on the engines have a section therein for each game? Seems like it would be a good compromise if we have no real intention of covering individual games in depth, but I don't know how that would affect search rankings. Blzut3 (talk) 20:46, 2 June 2015 (CDT)
The In Persuit Of Greed source code and all assets have been released, -- Shambler (talk) 04:02, 24 June 2015 (CDT)

Skin issue[edit]

It seems that pages in the File: namespace always use Monaco now. Set your preferences to MonoBook, then look at a random example. What you see will not be what you'd expect, but this. --Gez (talk) 13:18, 12 June 2015 (CDT)

My first question is, when did "now" start? --Quasar (talk) 14:23, 12 June 2015 (CDT)
Also, I cannot replicate it. I have set myself to MonoBook and so far, all File articles have the expected appearance. --Quasar (talk) 14:26, 12 June 2015 (CDT)
I first noticed it yesterday. Though after you said you couldn't replicate, I forced a full reload and now it works. Very odd. Well, problem solved I guess. --Gez (talk) 14:42, 12 June 2015 (CDT)
Browser caching or cookie issue maybe? Keep me posted if it returns. --Quasar (talk) 14:53, 12 June 2015 (CDT)

Category: Fun ?[edit]

Given the recent destruction of a tongue and cheek article (that I won't bring up for obvious reasons, my bad), I propose a category for "funny" articles that describe a topic in Doom, Doom games, or the Doom community, but can't really be put in a factual context without losing the "funney". I'm not saying we should have a category for "Uncyclopedia" like content as that may encourage vandalism, but this would be a perfect catch-all category for community in-jokes like "Ball shit snakes", "frad", "Nick Bakery", and other silliness that can be somewhat notable due to it shaping a sense of community in its younger years. Or, maybe the article could be for finding humor in historical high-drama situations the Doom community always wades itself into.

Is this worth a shot? ConSiGno (talk) 16:27, 12 June 2015 (CDT)

Community in-jokes should absolutely be included.  A few already are.  For the simpler ones, maybe start a sandbox glossary and encourage people to add what they remember, and bring it live when ready?  (A sandbox is basically undeleteable unless you're committing a felony or something.)  Myself I've always wondered about the origin of "heh".    Ryan W (talk) 17:02, 12 June 2015 (CDT)
Alright, I'll get right to it. Considering how many community-specific terms and fads this community has and has had by now, some of the better ones need to be written down. ConSiGno (talk) 18:02, 12 June 2015 (CDT)
Should they have individual pages or could they all go in one "Community in-jokes" article? Also, cran time. --Gez (talk) 05:23, 15 June 2015 (CDT)
Looks, tastes and smells good, à la [[Category:Silly]] on Wowpedia. --Kyano (talk) 09:02, 15 June 2015 (CDT)
We discussed on IRC the possibility of having a "Humor" namespace that keeps non-canonical stuff separated fully from the purely encyclopedic content. The namespace could even be protected so that only admins or approved users have the ability to create, edit, or move articles into that namespace. This would be a suggestion in addition to CSG's documentation of community memes, which *is* encyclopedic and would belong in main space (so long as we are taking enough care to not tread into defamatory territory; I have a few minor concerns with some of the WIP articles that might merit discussion). I would like to collect opinions on this proposal at the same time. I only have two ideas for articles that would go there currently, and they're the deleted version of "Cutscene psychosis" and the old revision of "Sotoxi," both of which, while "crap" as encyclopedia articles, were actually decent humor. Other wikis have some things like this, to a much greater extent. See in particular Transformers, where they long ago decided their long prose technical descriptions of plastic children's toys required some levity injected in the form of humorous image captions. Having a restricted namespace for a limited number of off-the-wall articles is nothing even close to that level (which is not the kind of thing I'd ever suggest for this resource). The Zelda wiki on NIWA has a method of dealing with "fanon" - ie. rampant fan theories, which in that community are are a big deal - even within its main space articles, using a special template and requirements about how the information must be delineated and separated out from canonical encyclopedic stuff. Again not appropriate for here, but another good example of a minor compromise made to engage the community with the resource. --Quasar (talk) 09:43, 18 June 2015 (CDT)
I am concerned about "that" article for more reasons than that! I could try to "un-slant" it a bit and make it a little more fair to the subject matter. ConSiGno (talk) 10:07, 18 June 2015 (CDT)
I think I was skeptical on IRC, but I'm coming to believe that Quasar's proposal is the way to handle these topics.  Some memes and in-jokes are part of community history.  Some were made up at the bus stop one morning and never will be.  The former belong in article space and the latter do not.
If a new namespace is created, I hesitate to endorse locking it unless there's actual disruption (maybe test the config changes and then comment them out?).  It's never good to preemptively bar good faith edits, and humor is too subjective to assign an unrelated small group to filter it (this is a flaw in the Transformers and Homestar Runner projects IMO).  On the other hand, I see the argument for being conservative; like all gaming communities, we have people whose sole contribution is to post speculations at ridiculous length, then abuse and troll anyone who suggests they're schlock (which they usually are).    Ryan W (talk) 20:40, 18 June 2015 (CDT)

Doom "4" Confirmed for Spring 2016[edit]

I am renewing the suggestion that Doom 4 be moved to Doom (2016) after one week from today (delaying for SEO purposes), now that a release date goal has been set. --Quasar (talk) 22:41, 14 June 2015 (CDT)

OK. --Gez (talk) 05:22, 15 June 2015 (CDT)

License change[edit]

It was previously agreed that it would not be objectionable to migrate to the CC BY-SA 4.0 license, and I have been asked to reactivate and carry out the proposal. After some interesting revelations in the wake of the Bethesda E3 conference, I feel this is a very good idea at the current time, in order to better protect any unique content we may develop in the near future regarding the upcoming title. I will be posting the mandatory global site notice for a change to the Terms of Use, after which we can start changing all of the licensing information on-site and within the backend. --Quasar (talk) 20:11, 15 June 2015 (CDT)

id Tech 6 article[edit]

There really should be one, although I'm not sure if anything of real value can be said yet. It could potentially expand on what changes have been folded over from id Tech 5 since Tech 4. --Chungy (talk) 14:57, 20 June 2015 (CDT)

A recent interview with Pete Hines revealed some interesting information in this regard which would serve at least as seeding points. Mainly, as we previously conjectured, megatextures are largely out, and dynamic lighting is back in, so in many regards it is a return to id Tech 4's technological basis. --Quasar (talk) 15:39, 26 June 2015 (CDT)

Cacoward winner category[edit]

Runners-up in the Cacowards with articles are currently categorised as Cacoward winners, which seems a bit misleading to me. Proposing they be split off into a separate category --Eris Falling (talk) 12:12, 27 June 2015 (CDT)

Some are, some aren't.  Good idea though.    Ryan W (talk) 13:04, 27 June 2015 (CDT)
Just for reference, if you want to link to a category, do it this way: Category:Cacoward runners-up. And yeah, if you want to create the category, it's fine to recat everything that fits; no objection. --Gez (talk) 13:09, 27 June 2015 (CDT)
Or use Template:Cat if you don't want the prefix, as such: {{cat|Images by content}} -> Images by content --Quasar (talk) 22:08, 27 June 2015 (CDT)

Criteria for inclusion in the genealogy table[edit]

This was touched on by Fraggle recently but was independently being discussed by a few people on IRC about a month ago. The question is do we need an agreed criteria for what constituted a "based on" port? My view is yes, and some things that are currently included should be removed to make the tables simpler. I think the trigger for me was PrBoom#External_links. However, I do feel that all the information about what took what from where, even if it is not sufficient to be considered "based on", should be retained, so I would like to figure out where that could go on the wiki before removing it from anywhere else (assuming that was consensus). As part of that thinking, we got onto thinking about the Genealogy tree. Someone took another stab at importing the information from Quasar's 10 years graphic into a graphviz file, this time licensed compatibly with the one true Doom Wiki. It needs a lot more work, but we could perhaps have a convention of colours or lines styles to differentiate different types of code borrowing, from a few routines to a full blown "based on". -- Shambler (talk) 02:04, 16 July 2015 (CDT)

I simply don't think there is a set of hard, fast rules that will cover every situation satisfactorily. And I'm sorry that PrBoom's revision history is such a mess, but I still fail to see how the table does not reflect what historically happened. It started derived only from Boom v2.02 and was a direct port of it to Windows using custom system code. Then, for portability's sake, it absorbed almost whole two existing SDL ports' codebases. This to me constitutes a genealogical relationship. It has the whole of their additions in it. Now is it always necessary for the WHOLE code to be present? No. Doom64 EX started as a derivative of Doom 3D. In the process of making the damn thing work, Kaiser nearly rewrote all of Doom 3D's distinctive code (including its barely functional Direct3D-based renderer). But, this proceeded in a piecewise, organic fashion, a similar process to biological evolution in my mind. This to me also qualifies as genealogical descent.
Strife is another good example. We don't have the source code for it, so we have to base things off the reverse engineered binary. But when this is done with a high degree of accuracy, I still see it as genealogical descent. Same applies to Doom64 EX. A recreation of code from its binary representation is still descent, just not in the usual manner.
It should be kept in mind that the genealogy box is a derivative of Wikipedia's Succession template, and that I originally intended it to have similar usage. For an example, see George_Gordon,_1st_Earl_of_Aberdeen#External_links. Notice how separate titles or disjoint terms of holding an office start new rows in such tables. This was the intent seen on articles such as PrBoom - when they were rebased on new descendents, it represents a genealogical/evolutionary leap, in my mind. It is misleading to indicate that PrBoom was originally derived from LxDoom and SDL Doom.
That the same has not been applied to Chocolate Doom and ZDoom was either out of laziness, or in the latter case, because the sequence of derivation additions is too complex to untangle. Good luck hunting down for instance the exact point when you'd consider ZDoom to have started to be based on Heretic and Hexen. v1.18 had about ~75% complete Hexen support from my memory; would that qualify as derivation? That's getting way too far into philosophical matters - the kinds of arguments that William James would have had issue with in his treatises on pragmatism, most likely.
--Quasar (talk) 11:03, 16 July 2015 (CDT)

Possibility that will change domains[edit]

There is still a distinct possibility that Doomworld will not be able to acquire the domain name from its current owner. Until this is resolved, we need to be on high alert of the possibility that all links on the wiki will have to be changed over. The amount of work this entails cannot be underestimated and it almost certainly cannot be accomplished without some degree of automated assistance. It looks like the new domain name, if it is required, will be "" --Quasar (talk) 00:33, 25 July 2015 (CDT)

I'm not sure this will require that much work. Thanks to the use of templates for links, we'll only have to update {{ig}}, {{ig2}}, {{igmm2}}, {{idgames}}, {{idgamesmm}}, {{dwforums}}, {{dwforumsp}}, and the handful of pages that appear here. Links that cannot be templated easily include those that are in {{cite web}} templates, so maybe something could be worked around for that, either a new template or a new parameter for cite web. --Gez (talk) 01:13, 25 July 2015 (CDT)
Marv was just asking what name servers the DW guys want to use yesterday, I'm pretty sure he's transferring it over. -- Jmtd (talk) 02:26, 25 July 2015 (CDT)
But it was just last night on IRC that Linguica described the domain owner as an "unreliable narrator" and was still expressing doubts, so I chose to make this a priority action item. Preventative action now like Gez's template changes will prevent a sudden mass of dead links if the transition fails for some reason and are worth the time spent. --Quasar (talk) 12:41, 25 July 2015 (CDT)

Compromise at the "other wiki"[edit]

There are rumors abounding that wikia's central user database was compromised. If you migrated your account here from there, please ensure that you are not using the same password you used previously. I have activated a global site notice regarding this. Please note that it is not that has been compromised. This is only of concern if you reuse passwords at multiple sites. --Quasar (talk) 12:51, 11 August 2015 (CDT)

Openings for new admins[edit]

I am asking for desiring members to apply here for administrator status, as the current understaffing cannot continue and keep this site functional for much longer. It has been at least three weeks since any meaningful conversations on Talk pages or RFCs were commented on, let alone advanced toward resolution, and there has additionally been no discussion on IRC in nearly the same time period. This is unsustainable. In order to be a candidate, you need to be a member of the editor group with an excellent editing history and a promise to actively contribute for an extended period of time. Current admins may object here, but should be prepared to explain their decreased participation as part of the response. --Quasar (talk) 11:24, 20 August 2015 (CDT)

I will also extend this as a reminder to ALL users that they are welcome and encouraged to comment on issues here, on article talk pages, and on RFCs. Enough participation from normal editors would relieve any need for additional admins. This used to occur at a high rate, and has been totally non-existent as of late. --Quasar (talk) 12:05, 20 August 2015 (CDT)
I'll start participating a bit more as work has died down a bit. ConSiGno (talk) 12:25, 20 August 2015 (CDT)
I applaud Quasar for breaking with tradition by describing some qualifications, but these backlogs don't seem to require adminship (including the oft-discussed FlaggedRevs; see below).
Totally agreed that low traffic is a huge deal, maybe our biggest on-wiki issue.  We know the internet includes experts on every Doom topic.  How do we get them interested in our threads about file hashes, person notability, console soundtracks?
Since you ask, my own absences have two causes: real-world crap, which unfortunately sets its own hours, plus half my recent edits being controversial.  The latter might mean that standards of quality have risen since 2005, or that I got dumber.  Regardless, I set an initial goal of increasing my value to zero plus epsilon [1] [2].  If that goes OK for a while, I'll reevaluate.  (I considered asking for demotion too, in case the potential for damage outweighed my current activity level [3].)  I have read all those talk pages and RFCs, and if I didn't post, it means I had no substantial opinion.
I can possibly help with pending changes provided we define the lowest approval level.  Currently there is no guideline and some implication that all edits must be fact-checked and judged within hours of submission [4].  If that's so, more power to the project, but I'm unqualified.  Same goes for the new formatting proposals.    Ryan W (talk) 17:37, 20 August 2015 (CDT)
On the lattermost, I am waiting for feedback on my idea to implement additional buttons on our wiki editor toolbar that would make our templates easier to use. I'll assume you agree that's a good idea. I can't really see it as being controversial. --Quasar (talk) 01:48, 21 August 2015 (CDT)

Bethesda GOG offerings[edit]

As noted in my breaking news post, Bethesda has suddenly taken to selling on GOG, so it looks like we need to create an article similar to Steam, as well as updating articles such as How to play Doom on modern Windows systems and How to download and run Doom. --Quasar (talk) 08:44, 26 August 2015 (CDT)

Yes, also added it to the Timeline. As of right now I don't think there's much more to say in the articles... But I'm very happy about that development! :) Hopefully Heretic/Hexen are next, and of course we're still waiting for Strife. --Gez (talk) 09:33, 26 August 2015 (CDT)
Is the first article still necessary after the second one has been cleaned up? --Chungy (talk) 19:15, 31 August 2015 (CDT)
(Sub-thread resulting from this question was moved to the article's talk page.)   Ryan W (talk) 21:02, 2 September 2015 (CDT)

Source Port repository for reference?[edit]

A heavy source of frustration when discussing technical elements of doom and source ports has been the lack of a central repository to reference them. A lot of source codes for notable source ports are scattered about the web in a myriad of archive formats, and can be hard to reference in online discussion or even in wiki articles without a local copy of the source code. Would it be in the best interests of the Doom Wiki to have a git repository of notable-yet-dormant source codes? SMMU, Boom, MBF, RORDoom, DOSDoom, DelphiDoom, CDoom, Legacy v1.28, and many others come to mind. For those still in development, perhaps a wiki article with links to said repositories for reference could be compiled. GitHub comes to mind first, as it allows for links to highlighted lines of source code. 13:25, 31 August 2015 (CDT)

It might not be entirely appropriate as a project of the wiki itself (I'm not sure), but it's definitely not a bad idea to import such things into Git; at the very least, it provides a non-obtuse way to obtain and browse the source code (versus Zip v. tar.gz v. RAR... are the trees consistent in structure between versions?). Personally, I've had some experience with converting old projects like this, for Doom utilities, there's a small selection in the Doom-Utils GitHub organization where I've done it (and all but LMPC I've updated since then, primarily for building on modern systems... but the original trees are still completely accessible and tagged). In reference to SMMU specifically, fraggle converted the old CVS repository here. --Chungy (talk) 15:00, 31 August 2015 (CDT)
Excellent news that some are already uploaded! Links to these on a dedicated page for editors would be great. Since GitHub has passed "fad" status a few years ago I see it as a relatively safe place for source code, at least as a source, when citing lines of code. ConSiGno (talk) 15:36, 31 August 2015 (CDT)

mobile theme broken for diff pages[edit]

Diff pages always come up as blank for me, when using the mobile theme. This is on an android phone and an iPad. If one visits a normal page and switches to desktop theme one can access diff pages, but the setting isn't particularly sticky: I'm frequently moved back over to the mobile theme (this edit page switched back to it for instance) -- Jmtd (talk) 01:21, 2 September 2015 (CDT)

The moving back is caused by the cookie expiration time being set too short. Other users have the same complaint. I have no idea what the problem with diffs would be and it sounds like a bug in the MobileFrontend extension. You should report it to the developers. Though, they will not currently accept your report because we are on an unsupported version currently. --Quasar (talk) 09:16, 2 September 2015 (CDT)

SyntaxHighlight-GeSHi will be removed[edit]

Due to the wonderful MediaWiki developers overwriting the GeSHi syntax highlighter extension with a new pet project which has dependencies on Python, we will be removing this extension before upgrading to MediaWiki 1.25, and the syntaxhighlight and source parser tags will no longer be available. We need to find all affected articles and remove those tags ahead of time. --Quasar (talk) 13:17, 26 September 2015 (CDT)

MediaWiki manual claims that search looks through the source of a page and can therefore be used to search for tags. I found only one result for syntaxhighlight (this very project page), and while there were plenty of results for source ctrl-Fing for <source gave me only one result: PLAYPAL. --Gez (talk) 13:30, 26 September 2015 (CDT)

Less intrusive stub indication[edit]

I am curious what others' thoughts would be on having a less intrusive option for indicating stub status on articles like minor source ports where the article is difficult to research or unlikely to be expanded on in a reasonable amount of time and where the normal article-top stub template creates an unsightly layout issue. I'll note that Wikipedia has taken to indicating *all* stubs in this manner, with a small notice at the bottom of an article instead of at the top. I am not looking to go that far but rather have it as a secondary option for cases like this; call them "lower priority" stubs, if you will. --Quasar (talk) 13:06, 9 October 2015 (CDT)

I like this.  "Reasonable" would mean, IMO, that we're not waiting for former id principals to release more files, or for technical analysis of a 1998 port on a dead OS.  Expansions involving playtesting which could be done by anyone, or information readily available in the vanilla source, should retain the original tag.    Ryan W (talk) 03:21, 4 December 2015 (CST)

Suggest new Category: Free and non-free (as per DFSG, OSI, etc.) ports.[edit]

How about a new category for free and non-free source ports as per the OSI? GhostlyDeath 01:04, 30 November 2015 (CST)

I don't really think this is necessary, especially not in such broad terms that imply anything other than DSL or GPL is actually in use for source ports, at least for anything derived directly from Doom. There are very few exceptions in the case of clean-room implementations, such as Rust Doom being licensed under the Apache license, but I still don't really think it's useful to add a category for that... --Chungy (talk)
I also don't think this is necessary, and furthermore the OSI doesn't define "free and non-free", they define "open source" and "closed source". The definition of "free software" is by the FSF. If we go with "open source", then you have a "closed source" category with ZDaemon and perhaps a couple obscure and long-forgotten ports that had one release and were abandoned in the 90s. If we go with "free", then you'd have ZDaemon, but also ZDoom, GZDoom, and Zandronum because they contain code under a non-commercial license, which makes them non-free according to the FSF. In either case, pretty much everything that's not a Z-port would be in the open/libre category. --Gez (talk) 05:44, 3 December 2015 (CST)

Freely licensed photos of the Doom toy guns[edit]

I recently contacted Blackmantis on the Doomworld forums who has been collecting the different types of toy guns that were photographed to make Doom's weapons. He's kindly agreed to license them under cc-by-sa 4.0 so that we can use them - you can find a gallery of the photos here. I've uploaded a few already. If you want to upload others, please credit James "Blackmantis" Tingle in the image description. Fraggle (talk) 09:57, 1 December 2015 (CST)

We have a special page, Doom Wiki:Grants of permission, if you want to add the info there. However, I am not sure if CC BY-SA can be applied to photographs of toys. WikiMedia policy would suggest otherwise. It is not possible to upload images of toys to the Commons, for example. The problem is that CC licenses imply you possess all of the rights to content in an image and that cannot be the case for the design of a non-utilitarian three dimensional good. This limits the legal use case to fair use. --Quasar (talk) 16:19, 1 December 2015 (CST)
Where is this implied in the license? Also, to be truly legal you will have to hire a lawyer who can tell you if uploading a picture of a toy gun is legal or not. GhostlyDeath 11:23, 2 December 2015 (CST)
The act of applying a share-alike license implies you own all the content. In particular:
You may not offer or impose any additional or different terms or conditions on, or apply any Effective Technological Measures to, Adapted Material that restrict exercise of the rights
granted under the Adapter's License You apply.
So in other words if someone wants to use a photograph of a toy you created to reproduce that toy in three dimensional form, that right is being granted to them by the CC BY-SA. To restrict that right violates the terms of the license, and therefore you simply cannot legally license something you don't entirely own under CC. This is common knowledge. IANAL, but I HAVE done a ton of research on trying to understand these issues as part of my responsibilities as an operator of this site. A link to review: --Quasar (talk) 11:42, 2 December 2015 (CST)
Question is though, do you own the toy once you buy it or do you only have a license to use the toy? Also depends if the toy design is patented. As seen in the past with much more advanced computers and vehicles, if it does not have a patent then it can be cloned. The only thing that cannot be cloned is any trademark, registered or otherwise. GhostlyDeath 14:02, 2 December 2015 (CST)
No, it's a matter of copyright. Read the article that Quasar already linked. Fraggle (talk) 14:06, 2 December 2015 (CST)
Also, just to be clear, I am super-happy to have these images and I hate even having to bring this kind of stuff up in the first place. I've wanted pics of the toys that we could use for a long time, and having the author's permission is what we need to make that happen. I think it is perfectly fine for us to host them, but I believe we can only flag them as fair use images, given all the facts. We can still require attribution be given for their reuse just the same as would be the case under CC BY-SA. --Quasar (talk) 11:47, 2 December 2015 (CST)
It's good to know - thanks for the heads-up. I had no idea this was the case. Fraggle (talk) 12:10, 2 December 2015 (CST)

Here's how it works in the real world: take a photo of anything, modify one pixel somewhere, this is now your own artwork. References: [5] [6] But maybe that's only true if you're a rich prince... --Gez (talk) 14:08, 2 December 2015 (CST)

Yeah there's the law in word, and the law in action. I try to avoid drawing too many conclusions from case law (particularly any individual case) and look to make the strongest possible cases for fair use when they exist - our templates spell many of them out for that reason. That suit sounds like a mess and I'm not sure I agree with the verdict. --Quasar (talk) 14:37, 2 December 2015 (CST)