Revision as of 18:21, 19 April 2016

Welcome

Thrilled to have you contributing here. I have given you "editor" status so that your changes will automatically go live w/o waiting for review, as I trust and respect your long experience in the community in regards to the "deep history" from the 90's. I've done my best trying to document that stuff, but a first-person perspective is always going to be superior. Happy editing ;) --Quasar (talk) 11:32, 29 January 2016 (CST)

Re: Welcome

Thanks, that's very kind, as was your presidential reference when creating my steward page. :-) I have some prior experience editing a simpler wiki (TrackMania) but am new here, so you may still want to keep an eye on my edits for a while, in case I make an accidental faux pas against content policy, style, or somesuch.

I'm not sure how long I'll be active here, but for the time being I won't run out of pages to read (and perhaps contribute to). ;)

Btw, is it possible to tie this Xymph page to my Frans_P._de_Vries one somehow? --Xymph (talk) 13:21, 29 January 2016 (CST)

Your person article is considered the encyclopedic one about you, while User:Xymph is free for you to use to describe yourself in whatever terms you like, without restrictions on content above our terms of service (you might see User:Quasar versus James Haley (Quasar) to see the difference). If you would like for your person article to be named Frans P. de Vries (Xymph), like most other person pages, I can do that as a move and leave a redirect in place. At the time I created your article I wasn't aware that you had a handle. --Quasar (talk) 13:31, 29 January 2016 (CST)

Ok, starting to get the hang of these discussion pages. Yes, then please rename my person page, thanks. --Xymph (talk) 16:15, 29 January 2016 (CST)

Archive links

Hello!  Wow, lots of mop-up; I like it.  :D

I think you have changed a few external links referred to here.  Are you doing this systematically, and if so, would you mind dropping a note somewhere when you finish?  I'm planning to scan a database dump to find removed links, but if I do that right now, I'll waste people's time if some cases get fixed by you simultaneously.  Hope that makes sense, thanks.    Ryan W (talk) 17:20, 9 February 2016 (CST)

Hi, you're welcome. :) No, the method to my madness ;) is not related to that list. Rather I went back to pages where I fixed archive links earlier the old-fashioned way, after Quasar showed how to use the template. I may fix more archive links as I encounter them, but am not specifically looking for the Romero ones. Are you saying this will be addressed a more systematic way? Then I won't bother. --Xymph (talk) 02:27, 10 February 2016 (CST)

Please don't stop fixing links if that's what you want to do right now.  My idea wouldn't make changes, only define the scope of the issue (addressing is a longer-term prospect, to judge by Quasar's example suggestions).  By "systematic" I just meant "intended to eventually encompass all topic areas/categories".  If you don't have a to-do list of pages left to check, then I guess I can proceed.  Thanks.    Ryan W (talk) 06:27, 10 February 2016 (CST)

Been here less than two weeks – I don't have a to-do list. ;) Mostly I'm reading up on historical stuff that I know about, and try to contribute/fix what & where I can. I am also using search and Linksearch when I encounter one bad link to find related others. Considering the size of the wiki, I'm not sure when I'll be done with that.

Btw, why do you like nbsp's so much? :) Or are they inserted automagically somehow? --Xymph (talk) 06:56, 10 February 2016 (CST)

Gosh, no one's ever asked me that so calmly.  :>   I think it started because I had never edited a wiki before and wanted every post to be perfect; the sentences just looked jammed together on the screen.  (I've since been assured the latter indicates senile dementia [1]).  Nowadays I think it's an anti-gestalt exercise, forcing myself to reconsider each sentence individually so I don't copypaste them into drivel.  The extra spaces are for discussions only, never "reader-facing" content.

And you're right — a link often implies the use of similar links in related articles!  That sure wasn't the case when I joined.    Ryan W (talk) 18:04, 10 February 2016 (CST)

Itty-bitty formatting

I understand. No really, I do, :) because when writing plain text (e.g. emails) I also use double-space after sentences, for much the same reason (and the --uniform-spacing option of fmt). But elsewhere that is frowned upon (e.g. Word squiggles them) or has no visual effect (HTML), so I don't bother. While we're deep into formatting nitty-gritty, I also noticed the lack of '--' in your signatures. You don't use the easy button? --Xymph (talk) 03:08, 11 February 2016 (CST)

IME the ease of those buttons is outweighed by the tedium of going back and forth to the mouse each time and targeting.  (I'm no doubt in a small minority; some contributors have used mouse-aim in FPSes every day since gastrillation.)  My browser not supporting them until 2011 may also be relevant.  If I start misspelling stuff like {{wp||}} and not catching it in preview, I suppose I'll reconsider.  :>

Much bigger tangent: OMG THANK YOU for dmpsmu.  I'd never have beaten Doom II without it!    Ryan W (talk) 10:13, 11 February 2016 (CST)

Map printing

Gotcha. And you're welcome, it was a lot of fun learning PostScript and developing that tool. Btw, what tool is used to create the maps in this wiki? --Xymph (talk) 13:13, 11 February 2016 (CST)

If I may intrude on this conversation, most of the maps were created with omgifol, though a few of the more recent additions were created with SLADE 3 (e.g. File:ETERNAL_MAP33.png). --Gez (talk) 14:42, 11 February 2016 (CST)

It's worth mentioning before getting excited about SLADE that you need to adjust some well-hidden power user features in it before its images will be acceptable for use here (some recently were uploaded w/o these settings tweaked and the maps are problematic as a result and will have to be replaced eventually). They are: the background color must be changed to #ffffff versus the default of transparent, and the line thickness must be increased by a factor of at least 3 to render acceptable scaling. I did request that the defaults of these be made wiki friendly in SLADE, but apparently that request was either rejected or is stuck in the program's long release cycle somewhere. --Quasar (talk) 16:46, 11 February 2016 (CST)

I don't see this request. --Gez (talk) 04:12, 12 February 2016 (CST)

Given the above finicky details, and the recent discussion of map scaling, I was wondering what exactly is involved in creating wiki-suitable images. After the above pointer I installed omgifol, but never got it to work ("IOError: Invalid directory information in header" when attempting to output MAP01 from doom2.wad).

I didn't touch SLADE3 yet, but getting its settings correctly adjusted seems non-trivial. Contributors currently uploading map images seem to be in the know, but where is this described for newcomers? Is there a how-to article I haven't found yet? If not, it would be helpful to add it. Given my past dabbling in map printing, I have a soft spot for this topic. :) --Xymph (talk) 04:00, 14 April 2016 (CDT)

Width, height, and line thickness settings can be changed in Edit->Preferences, Advanced tab, all map image settings are prefixed with "map_image_" so they're easy to find. The colors, on the other hand, are changed in the Interface->Colours and Theme tab, "Map Image Export" section. Click on the little + in a box to get to the opacity setting. --Gez (talk) 07:12, 14 April 2016 (CDT)

After some installation trouble (my PC took so long to install "VC++ redist 2015" that at first I thought it hung up) I got SLADE3 map printing to work with your settings, thanks. And the built-in tutorial to map printing also helped. But now your tips are buried in this discussion thread. What about adding them to the Wiki FAQ or some other central location, together with guidelines on scaling (if and when that discussion is continued and resolved)?

And if omgifol is still in use, add the same for that? Or is it de-facto obsolete due to SLADE3? --Xymph (talk) 08:35, 17 April 2016 (CDT)

IMO style guidelines should have their own page now, because they're numerous and (seemingly) almost always applied in different edits than the actual content changes.  An "images" section on that page could then describe these considerations as well as the oft-discussed aspect ratios, screenshot HUDs, etc.

omgifol is obsolete in the sense of being unmaintained, but AFAICT some contributors still use it regularly.  It's good to have multiple options anyhow (zounds, SLADE even runs on Macs).

BTW, category links go like this: [[:Category:Alistair Brown levels]] → Category:Alistair Brown levels.    Ryan W (talk) 18:21, 19 April 2016 (CDT)

Deleting pages

Hi again.  We're always grateful when people want to help with something boring and tedious :>  but in this case deletion is one of the tools reserved for administrators.  If and when you feel you have a good grasp on what kinds of material belong on this site and what don't, and you run across a less blatant case, you have the option of tagging it for deletion, or even for speedy deletion if it seems to fit one of those descriptions.  (Today's example would have been wiped out immediately by any admin who logged on, I think.)  HTH.    Ryan W (talk) 17:59, 15 February 2016 (CST)

Thanks for the explanation, shortly after blanking it with my comment, I realized it was a rights issue. And that's fine, good grasp here I have not yet. ;) --Xymph (talk) 03:01, 16 February 2016 (CST)

Archive links

For the most part, the latest revision is the best, but, make sure that when dealing with citations in particular, that the cited material is actually appearing in that version; if not, finding the latest version where it still appeared (via bisection if necessary) is the process I usually use. You also need to avoid any entries that redirect, throw the user to a non-working age page or user login prompt, etc., but I figured that's probably already implicit in what you meant by working anyway ;) If you find any created by me that didn't use the latest version, there was probably a reason for it. --Quasar (talk) 09:33, 16 February 2016 (CST)

Thanks for the additional context, I'll keep it in mind. --Xymph (talk) 10:30, 16 February 2016 (CST)

Rollback

My apologies, once again. In view of the recent spam crisis I've been experimenting with phone edits, so as to be able to check in more often. It is clearly out of control though -- even in my most active period I didn't need reversion once in every three contributions! Won't happen again. Ryan W

Yeah, figured something was going on with tiny buttons and big (fumble)fingers. :-P --Xymph (talk) 16:50, 22 February 2016 (CST)

Section structure in map articles

Answering all those questions would be an earful, but I'll try it if you're really interested.  :D    Ryan W (talk) 14:29, 20 March 2016 (CDT)

Well, if you can muster a Reader's Digest version ;) they yes, I'd like to learn more about it. --Xymph (talk) 14:36, 20 March 2016 (CDT)

Articles about stock PC maps, unsurprisingly, originate in the first weeks of the wiki.  For the most part they were added en masse, one WAD at a time, by whomever arrived first with a script to generate the barebones markup.  Only Fredrik knows for sure, but I'd speculate that the quantity of topics covered was our main priority for a while, far above mutual consistency and coordination (certainly there are few or no on-wiki style discussions), so the articles' formatting had small differences from WAD to WAD.

Over time, these differences then propagated to newer map articles via copypasting, producing the "mishmash" you noted.  {{wad skel}} and {{map skel}} were attempts to standardize after the fact, but even when we'd accepted them as defaults, no one went back to revise the 300+ existing pages.  Since then, the "mishmash" has persisted because:

1. Blank map pages are still created by a small set of contributors, who also don't coordinate, tending to copypaste from their own previous work.
2. The average Doom fan isn't especially detail-oriented or technical, seeing himself as a creative artist.  When working with wikitext, he accidentally erases paragraphs or reorders sections.  When trying to research map data, he usually gets bogged down in procedural issues and ends up writing from memory, making mistakes.  Years later a fellow Doom fan notices an error and rushes into fixing it, thereby replacing it with three subtler errors.  Multiply this by the number of prose subsections (walkthrough text, development history, trivia,...) across all popular maps, and you get the current situation.

The idea that all of our articles should be well-formatted, which I support, is fairly new.  IMO maps are particularly difficult to standardize due to their quantity, their potential length, and the many changes in our conventions and available tools since 2005.  I've noticed that when Quasar tests a new style proposal, he tends to avoid map pages.  :>   What you (and several others) are doing with the stock maps is unquestionably constructive, and I support it also, but the big-picture goal is still a long way off.  If we're serious about looking polished, somehow we must address the fact that map articles are created much faster than they are upgraded.

This brings us to your first point, the presentation of early Doom 1 maps.  When I joined the wiki, I said to myself, "The stock maps are an indispensable, central topic.  They should have uniform formatting so editors can easily see what to fill in."  Because the original games are widely considered ancient history (again excepting specialists such as yourself), articles about vanilla gameplay are a deep backwater, and feedback on my changes was extremely rare.  The only focused discussion I can find is this.  Eventually, after making sweeping revisions for over a year with no great controversy, I changed {{map skel}} and... silence.  So I guess that became the standard, at least in the eyes of some editors under #1 above, and was transferred piecemeal to a few other old maps.

In hindsight I probably got carried away intensively researching one map at a time, and should have started smaller, standardizing sections across all stock maps before trying to fill any in.  That's why the pattern stops abruptly at E2M9, which of course comes after E2M5.  :>   Had I done so, your current project would be much less tedious.  Then again, some power users might disagree, saying not to bother with a major revision unless it makes the article 95% complete: there is every chance no one else will take an interest for a decade.  (By such reasoning, e.g., this is not better than nothing; it's embarrassing when someone googles a specific map title and basically gets a sticky note saying "content coming soon").  But that highlights another difficulty with improving formatting systematically — we don't all have the same concept of what "improving" looks like.

Hope that makes some amount of sense, and thanks again for your help.    Ryan W (talk) 18:22, 20 March 2016 (CDT)

Thanks for taking the time writing that up, very informative. That explains why the second model seemed newer and more common, being in use on most UDoom maps from E2M6 onwards – but only because of your abort in standardizing them – and also on a majority of Doom II maps. I used the term "mishmash" as those are interlaced so much: the first (and current) model is used in MAP01, 02, 05, 07, 08, 14, 17, 23, 25, 26, 29, 30, 32 (total 13) while the second (older) model is employed in MAP03, 04, 06, 09, 10, 11, 12, 13, 15, 16, 18, 19, 20, 21, 22, 24, 27, 28, 31 (total 19). Wacky :) but now I see how that came about.

As for sensible, 'Strategy' seems a better overarching term for Walkthrough/Other points/Secrets/Bugs than 'Walkthrough' does for Essentials/Other points/Secrets/Bugs. So the main section header and first sub-section one are the main differences between the two models. What was the reasoning behind that change?

So what is the big-picture goal regarding the Walkthrough section of map pages? How can I help (keeping in mind my main focus is on the classic UDoom, Doom II & Final Doom maps)?

In peeking ahead to my remaining Final Doom maps – I stopped after MAP12: Speed (The Plutonia Experiment) to raise this discussion – I saw that most pages from MAP22: Impossible Mission (The Plutonia Experiment) onwards don't even have the Essentials section written up yet, so I am willing to take a stab at those. But some existing Essentials sections consist of a simple numbered bullet list, like the aforementioned MAP12, while a more verbose paragraph structured walk-through is far more common. What is preferred, is there a style guideline for this? --Xymph (talk) 08:54, 21 March 2016 (CDT)

I can take responsibility for the mismash on Doom II level articles. When I was given Editor rights in 2012, I soon noticed that Doom II level articles were still unchecked. I started to give them FlaggedRevs grades and checked their content thoroughly for this (and also added new content such as screenshots). I changed the articles' "strategy" header model to "walkthrough" model as I had had the impression that it is the form we're supposed to use in the future. As other Editors started to rate Doom II level articles with me, I rejected the process as I felt I had more important things to do on the wiki. I wanted to select levels consistently from different phases of the game so I selected every third level starting from 2 and ending to 29. It seems that I never edited level articles 11 and 20, though. Oh well.

If we reach a consensus on which model to choose, I can go through Doom II level articles and change their header models accordingly.

One more thing: in retrospect, I think my screenshots and their descriptions (on level articles 2, 5, 8, 14, 17, 23, 26 and 29) should probably be brought up as they generally spoil level content more than, say, Ducon's screenshots. And strong stylistic differences on a single wiki aren't usually a good thing. But that's a completely different topic. --Jartapran (talk) 16:54, 21 March 2016 (CDT)

Jartapran, the above post was not meant as criticism of your excellent contributions on the maps.  You are always thorough, you ask for help when you don't understand, and you accept tasks which (I well know) are ridiculously boring.  I feel good whenever I see you editing map pages, even if I don't often say so.    Ryan W (talk) 18:44, 23 March 2016 (CDT)

Sorry; when I refer to "big-picture goals", I am speaking putatively.  There are currently no style guidelines or collectively defined big-picture goals specific to walkthroughs.  On this wiki, it is nearly impossible to conduct a big-picture discussion, regardless of topic.  (Maybe it seems too abstract, or too much like a workplace meeting...)  Change usually begins when one editor implements several test cases, waits for reactions, implements several more.  That said, it's your name on the diffs so it's your choice: you can try preliminary steps such as extending the existing thread, the talk page of one map needing major cleanup, a userspace draft, or even an RFC.

"What was the reasoning behind that change?"  — That was a long time ago, and unfortunately most participants have left the project.  For my own tasks, IIRC, I began by rereading every map article (all created, it seemed, by highly intelligent chaps who knew more about Doom than I) and listing all headers occurring at least once.  Due to the open-source engine and vast community history, my final outline was inclusive, assuming that almost every subsection could in principle be written for all maps.  My inspirations were the Prima strategy guide series and gamefaqs.com, though I sought to avoid the latter's convention of linearization, i.e. This room is full of spectres.  Kill them, exit to the south.  An arch-vile teleports onto the left-hand platform.  Deal with him, then pick up the blue key.  Even a newbie doesn't need prodding to defend himself in every paragraph for 32 maps; we describe the geography, then consolidate tactical advice into articles on monster species and weapons.  Possibly I went too far with this also, barely discussing combat at all in the narrative sections; my recent walkthrough draft attempts a hybrid approach, mentioning all monsters who are easily noticed.  Prima's Quake III book demonstrated the "layering" concept in that old E1M3 thread (not all readers have the same playing proficiency or immediate goal), and of course marked spots.  :D

Personally, I dislike the numbered lists.  The route appears more linear than it is, and the whitespace on the left seems to compress the text.  (Frankly this may be a geo-cultural bias; in another writer's formal education, numbered lists might look professional.)  Even the order of the secret sectors is ill-defined; I've arranged them to match the chronology of "Essentials" and "Other points of interest", but I have no idea what everyone else does.  On the other hand, when a map is long enough to need sub-sub-sections (e.g. individual keys), it does help to separate them visually with markup.  This, which I only noticed because of this thread, is a definite improvement over my method.  I still prefer "walkthrough" to "strategy" for the top header because the DM and speedrun analyses are also varieties of strategy, although there are jargon terms for each.  I'm not messianic about that anymore, however, and would use whatever standard we could all agree on.

Ultimately, all advice on writing walkthroughs is anecdotal, including this post, because we don't have a squad of newbies for usability testing.  Unless that happens someday, disagreements over style are inevitable (though hopefully civil).  By the same token, if and when we develop a format guideline for 2000+ map articles, some power users will find certain choices arbitrary, and must be open to compromise.

"How can I help?"  — I am likely the wrong person to make suggestions: when I'm not absent, I'm editing upside-down and backwards.  Since you ask, however, the following have accepted precedents and SHOULD be uncontroversial.

• Walkthroughs for E3M4, E3M5, and MAP18 are copied from Tim Brastow without permission.  They should be rewritten from scratch.
• Run the "F10, B" error check in DeePsea.  There are usually minor bugs we haven't yet documented.
• Find clashing tags (e.g. the yellow door on E1M4).
• Convert "Things" tables to the new format.
• Suicide holes, and situations where the player can become permanently stuck, should be identified in the text.
• For Plutonia, authorship credits should reflect the community's most recent research (or else note disagreement between sources when it exists).
• Tricks from Compet-n's "nostalgic" pages belong in the speedrun sections of the maps mentioned.

Wow, that's a lot of words, so I hope I answered your questions someplace.    Ryan W (talk) 20:39, 23 March 2016 (CDT)

Uhm, yes, thanks again for being your usually verbose self. ;-) I'll stick to the current map-skel section headers then. Personally, I don't need descriptions of the battles encountered throughout a map's walkthrough either, but I can see how it may sometimes be helpful to point out crucial situations. And I prefer not using numbered bullets for these sections too.

As for areas to help, I got more than I bargained for. :) I am not that interested in speed-running or technical stats, and am not going to install an editor or other tools. My question really pertained only to walkthroughs, so I'll see what I can do there, in Plutonia and then back to the other IWADs. I'm not sure what you mean by the remark about "authorship credits should reflect ... research" though – I don't follow the Doomworld forums and the like. --Xymph (talk) 04:40, 25 March 2016 (CDT)

Good thing I only included the small ones then.  ;>   Seriously, I perhaps read that as "how can I help in ways I'm not already trying/proposing?"  Clearly you arrived knowing that proofreading was laudable.  I hypothesize that re-standardizing the section headers is also fine (this isn't Wikipedia where every possible edit is objectionable to somebody), but that's merely my opinion.  You have begun to do so in the time it took me to see this post.  If you want to standardize the headers with some assurance that others won't unilaterally undo the work years later, that's quite another matter, and I listed some discussion channels above.

The history screed is mainly to show that there was a line of reasoning for the current content of {{map skel}}.  It's not the only defensible choice, as shown by your comments, and it's not necessarily the choice we'll make when we finally drag every map article into compliance.  (I personally believe that will require automation, in addition to community consensus on a style guideline, which is why I said it was a long way off.)

Yes, I realize how lame it is to post TODOs when I am rarely active enough to help [2].  :( :( :( :(

Regarding Plutonia authorship, I'm only dimly aware of the issue myself.  IIRC we've had mild edit warring in the articles, plus e.g. inconsistencies between this and this, but I wasn't able to boil those down to an answer at the time.  I mentioned it because you are familiar with the 1996 community and I am not.  :>    Ryan W (talk) 15:24, 25 March 2016 (CDT)

My 199[3-7] archives contain a lot of info, but little about Final Doom and nothing about their authors, so I can't help there. Standardizing section headers to the map-skel layout seems sensible to me (without further discussion), because that is the current standard. And it will aid future automated changes to whatever future standard is agreed on, if ever. ;) So I'll just carry on when I have some time. Thanks again for all your insights. --Xymph (talk) 07:32, 27 March 2016 (CDT)

Thanks

You keep catching my bone-headed mistakes before I have a chance to discover them 3 weeks later ;) --Quasar (talk) 14:53, 12 April 2016 (CDT)

Glad to be of assistance within more reasonable time-frames. :) --Xymph (talk) 15:48, 12 April 2016 (CDT)