Doom Wiki:Central Processing
This is the central discussion forum for wiki editing and administration activity on the Doom Wiki. Feel free to ask any questions or pose any concerns you have here, and you should receive a response shortly. Check the archived discussions for older threads. For extended discussion on long-range "to do" issues and project planning, please also visit our Request For Comment hub.
|2005 • 2006 • 2007 • 2008 • 2009 • 2010 • 2011 • 2012 • 2013 • 2014 • 2015 • 2016 • 2017|
- 1 2018!
- 2 Mass deletion of source port subpages
- 3 discussing systems/sysadmin/operational issues here
- 4 latest public wiki dump on archive.org
- 5 PWAD infobox change
- 6 Classic RBDOOM 3 BFG
- 7 localhost?
- 8 List of Wikipedia links (new automated task)
- 10 Update Doom Legacy
- 11 Zombieman and Possessed soldier
- 12 Yo yo yo
- 13 Deletion tracking?
- 14 Script-generated mapper stubs
- 15 Spawn points on DM/CTF map views
- Eh? 1994 discussions are where it's at. Ryan W (living fossil) 10:17, 4 January 2018 (CST)
- Hello everyone and Happy New Year. Fraggle (talk) 16:28, 4 January 2018 (CST)
Mass deletion of source port subpages
Please see here to give your opinion. This is effectively a deletion nomination even though nothing will be tagged, so it shouldn't be buried on a template talk page. :> Ryan W (living fossil) 08:17, 24 February 2018 (CST)
Update: This should now be completed. Please report any unexpected behavior in the port articles or on maintenance listings. (The latter is how I noticed the issue, but without reaching a solution, until Shambler did so.) Ryan W (living fossil) 00:14, 19 March 2018 (CDT)
discussing systems/sysadmin/operational issues here
It would be desirable to move lots of IRC conversations on these topics to the Wiki. Some of them are fine to discuss publically and could just be handled like any other wiki issue, on this page. However some I think are possible a little more sensitive. What do the admins think of us having some kind of hidden or protected page for those issues? (Of course, some might be too sensitive to put on the wiki at all. But not all.)
Some issues (not categorising them according to the above yet) recently discussed include
- backup process, frequency, improvements
- software updates
- general things about hardening
- thumbnail size issues
- Only a few people have the expertise and access to contribute directly regarding server issues. Ultimately, it's their decision whether recordkeeping and transparency are important enough to spend extra time documenting on-wiki (we are an all-volunteer project after all). As a wiki admin with neither, a few peripheral thoughts:
- Some tasks are by nature interactive, like upgrading or debugging. IRC is a better tool for that; there's no good reason to post "I ran this command and got an error" and wait hours for someone to read it, or copy 40K of logs for a post mortem. That said, I think it always helps sociologically to get news updates after the fact, especially when the rest of us can help by testing something or promulgating a process change. The last MW upgrade wasn't even announced in advance, which is not a good thing given it can potentially lock editing for days.
- It is virtually impossible, by design, to make a hidden page. (Maybe completely impossible, or Wikipedia would use them for arbitration deliberations and privacy cases and fifteen other things. But they don't; they create tiny spin-off wikis, with their own installs and subdomains.)
- Regarding any infrastructure matter, we will have users with expertise but not access, because the Doom community is so large. On-wiki discussions would (in theory) allow their knowledge to benefit us, and help them feel more involved. We made a dog's breakfast of delegation and inclusiveness during the fork: people offered numerous suggestions about configuration, Google ranking, authentication issues, and the strong impression is that they were totally ignored, even when Quasar and manc obviously didn't have time to research everything themselves. Most of those people stopped contributing to the wiki. We don't want to repeat that.
- Ryan W (living fossil) 07:06, 1 March 2018 (CST)
- Thanks for that. Given the futility of trying to have a private page on the wiki, I suggest we set up a Trello board for such things. In fact I just did. Could those admins interested in this (especially User:Quasar :)) please message me your trello login (once created if not already) and I'll add you to the board. -- Jdowland (talk) 06:26, 5 March 2018 (CST)
latest public wiki dump on archive.org
Completed today, a little over a year since the last one: https://archive.org/details/wiki-doomwiki.org-20180313
PWAD infobox change
Doomworld stated that Cacowards should be denoted by year (2004, 2005, 2006) rather than edition (11th, 12th, 13th). I'm preparing to change Template:Wad to match that (see also the usual rambling). Although I don't think this is controversial, I'm giving advance notice here, for the people who use the template often. OTOH if you do disagree, just say so and I'll hold off. Ryan W (living fossil) 23:05, 15 March 2018 (CDT)
This should now be complete. Let me know if anything looks wrong and it's not obvious where to fix it (I hope I didn't imply no one else was capable of adding 1993 to a number). I did not double-check every link in the body text, so if that didn't match the infobox before, it probably still doesn't. Ryan W (living fossil) 15:26, 17 March 2018 (CDT)
Classic RBDOOM 3 BFG
A new DOOM 3:BFG Edition modifiction/port has been released for quite a time now. It allow you to use classic DOOM arguments,load mods for DOOM 1 & 2, full controller support, fixes various glitches in classic DOOM and support Dehacked and it's BOOM extension.
When I get email notifications for updates on changes to pages, it shows hxxp://localhost instead of hxxp://doomwiki.org and the rest of the URL. Why is it doing that? Example here: hxxps://i.imgur.com/vVAhwS1.jpg Mrchris (talk) 15:22, 20 March 2018 (CDT)
- This was already reported on Doomworld Forums and an adjustment was made that should have fixed it. If you get another such email, please let us know. --Quasar (talk) 20:22, 20 March 2018 (CDT)
Xymph has done another amazing thing, tabulating every "reader-facing" link to Wikipedia. See here for the originating conversation.
I believe this is a useful resource, and if others agree, I recommend reading the talk thread and thinking about applications. It doesn't have to be a project you'd do now, or soon; it's just that if the script needs tweaking, that's easier while it's on the front burner. :> My own tentative ideas:
- Fix dead links by archiving, substitution, or replacement with the sources Wikipedia used.
- Do the same for links that work, but are highly vulnerable (e.g. pop culture taxonomies, 1990s gaming journalism).
- Clearly indicate when a link is a source, instead of shoveling everything under "External links".
- Identify background topics where we might expand our own coverage if community experts were willing (e.g. period PC gear, broader gaming history, relationships between fandoms and publishers).
- Scrape general references from Wikipedia talk pages, even if deleted (where there is one beige box there may be more).
The first three led me to propose the table (the third has unavoidable manual slogging, but I feel like it's partly my mess). I don't personally have a long-term goal of boycotting all wikis with corporate mission statements, but if some people do, this would help define scope at least.
Feedback on topic areas is also desirable because there is a way to get exports of deleted pages. Good will at Wikipedia is limited however (some say forbidden), so I would want to include everything worthwhile in one pass.
Fragmented threads are not amazing — I suggest keeping discussion here, and only commenting in the talk thread if you have code improvements in mind. Thanks, Ryan W (living fossil) 20:44, 28 March 2018 (CDT)
- Big thanks to you and Ryan W for great work on a tough job. For the past 5-6 weeks I was too busy IRL – and my brain too fried ;) – to be of any use there. --Xymph (talk) 11:11, 11 June 2018 (CDT)
Update Doom Legacy
I looked over the Doom Legacy page, and it needs updating again.
I considered bugging someone again to get it updated, then finally decided that I should get an account and do it myself. From reading the FAQs, I am not sure if the Wiki would rather that some neutral person do that (writing about yourself?).
I tried to get an account, using the name "Wesley Johnson". I got rejected because it is too close to an existing name "wesleyjohnson", which is me.
I tried to login using "wesleyjohnson", but that password does not work (from doomworld). I am never certain what password Firefox is throwing at a site, so that could be messed up too.
- You need to email me at haleyjd -AT- hotmail.com, with a message that you'll agree to send me on Doomworld as a privmsg to prove that it's you, and what email address you want to associate with your account here. At that point I can enter that email address into the database, and you'll be able to reset your password the normal way. --Quasar (talk) 22:30, 12 August 2018 (CDT)
Zombieman and Possessed soldier
The Doom Eternal Zombieman creates a weird situation in that, design-wise, it is a reinvention of the original Zombieman, but behaviorally, it is mostly a reskin of the possessed soldier. However, the two ingredients in this equation do not have much to do with each other, and one might argue that the possessed soldier's attack behavior is more like the chaingunner as far as classic monsters go, since he can fire repeating shots. So, suggestions on how to handle the monster versions template for those guys will be appreciated. My impulse is to only have classic zombieman and possessed soldier link forward to the Eternal zombieman, and not to each other. It's unprecedented, but it makes logical sense and doesn't draw a connection that seems spurious. --Quasar (talk) 01:52, 15 August 2018 (CDT)
Yo yo yo
Hey, could you remove my real name from my article please
- Looks like it was done, and links such as this one changed as well. Ryan W (living fossil) 11:13, 19 August 2018 (CDT)
Pages like this were discussed on IRC. The "front" content is deleted and likely to stay deleted, but the talk is not interesting enough to archive (i.e. unlikely to educate us for future cases). Are they clutter? IMO as a general rule, it's essential to document our decision-making for transparency, but even I don't go back to reread licensing rants. :>
Possible options include:
- Keep and don't categorize (status quo)
- Pros: zero implementation time; category system is much too OCD already. Cons: almost impossible to find these talk pages at all, except by manually comparing titles or logs.
- Keep and categorize
- Pros: better-organized institutional memory; easy to explain ourselves with new tag; precedents may someday need systematic review to update policy (if all attempts at consensus-building continue to fizzle). Cons: adds a step to deletion closure; importance of routine nominations inflated by lumping them with actual meaningful threads.
- Pros: removes clutter. Cons: uncomfortable mass admin action precedent; search rank reduction for fewer cumulative bytes.
Maybe people aren't concerned, but I thought it would be good to ask before potentially deleting so many pages! I'll be glad to do the edits, whatever we decide. Ryan W (living fossil) 17:44, 22 August 2018 (CDT)
- I'm for the 2nd option but I'm well known to be an archivist ;) As for the clutter, I can always add an argument to the new template that selects an alternate categorization for unimportant discussions, if that suits you better. --Quasar (talk) 18:45, 22 August 2018 (CDT)
- Option 2, with separate categorization for trivial decisions. --Xymph (talk) 12:27, 30 August 2018 (CDT)
Script-generated mapper stubs
After developing my latest bot script based on WAD/map/author information collected in the .ini files, my next idea was to use that same information to create new mapper pages as well. These naturally cover only an author's WADs and maps that are already covered on the wiki and configured in the .ini files, but it could be an acceptable start. I considered searching the idgames/levels/ text files for Author fields with the mapper's name/alias as well, but that is quite difficult because the Author field in the template is multi-line (so a simple 'grep -r' won't do), and .txt files are often inconsistently formatted anyway.
So for starters, the createMapper.php script only includes known, covered works along with a standard intro and the category/sortkey (if applicable). Author names with and without "(alias)", or just alias, are handled correctly (I hope, until the first case where the code fails is encountered). Works can be grouped per year if extensive or lumped together if concise. (Actually, the latter person's works may be extensive enough to group annually too, but that's easy to update.)
My questions: is this indeed an acceptable beginning to create missing mapper pages (and not just because any stub is better than no page, please)? And, any suggestions to change/improve the intro or other parts of the generated page? --Xymph (talk) 13:07, 30 August 2018 (CDT)
- XymphBot generating person articles, what a time to be alive! I think this is good as a starting point, it cuts stuff out of WantedPages without bloating the list with WADs that may not ever have articles. Personally, I believe all person articles should use the same format of grouping stuff by year, regardless of how much content is there. If there's very little content in the list to begin with, perhaps the article shouldn't be made in the first place, however, you do get notable people without significant mapping output, so there's that to consider as well.
- No issue with the leading sentence personally. Honestly, I don't know how you could say more in an automated process considering people are notable for different reasons - contributing to multiple Doom projects is just the common link :P --Eris Falling (talk) 14:20, 30 August 2018 (CDT)
- Thanks. I replaced the second example with someone where a level-3 year header would really be overkill IMHO, but who (like dew) is notable in another field (and was redlinked 40 times in total). Still, I'm open to further discussion on this point, as with any line it can become difficult deciding where to draw it. --Xymph (talk) 03:57, 31 August 2018 (CDT)
- I can't add much to Eris's points. :> A bot-generated page would also have map link formats correct on the first pass, which seem to need recurrent human fixes currently.
- It will be argued, on SEO grounds, that any stub is better than no page. It stops the search term returning 404 and increases our total content size.
- My only question is, how will the script account for the unstructured information a human contributor is expected to know? Obviously it must track these people. More often, there is a sentiment (not a consensus, just a statement here and there) that a person can release maps without all of them inheriting notability. This is an extreme example; no one ever added those to the list, even as a joke. OTOH the Doom community can decide that a person is so awesome, their unknown back catalog becomes interesting (like a box set for a musician), but that change isn't announced anywhere. Is there a continuum of judgement calls to be made in between, at least in coordination with the bot's edits? HTH folks, and thanks for all your efforts. Ryan W (living fossil) 12:44, 2 September 2018 (CDT)
- The answer is easy: it doesn't. The createMapper script merely compiles the WAD/map list with parameterized intro/outro, and doesn't even submit that via the bot account. It could but that doesn't add much "service" for me, so I submit it manually. Unstructured info can then be added by humans, like for any article. Thus, the script doesn't need to know about people that shouldn't be covered, as it doesn't make any autonomous decisions. I will decide which mapper articles to generate based on their number of redlinks and their WAD/map list, and if in doubt, will ask first.
- The mapperMaps script can make subsequent edits via the bot account, but only to existing structured information and only after my approval (the interactive comparison). So any coordination and judgment call goes through me, not the script by itself. --Xymph (talk) 03:06, 3 September 2018 (CDT)
Spawn points on DM/CTF map views
The recent addition of spawn points listings to DMMPST combined with Eris' maptabs idea I happened to encounter in his sandbox, prompted me to add drawing of DM/CTF spawn points to the Omgifol drawmaps script. Two examples are now online, as is the expanded script.
The color choices for the spots are analog to SLADE's, the yellow for the text comes from Eris' sandbox images. The spots include a small arrow/knob in the direction of the thing's angle. Because Python's PIL doesn't do anti-aliasing, the spots initially looked rather ugly. The poor man's anti-aliasing solution was to draw the image at increased scale (default 3 times larger), then resize it down using a PIL anti-aliasing filter. The code handles other alias-scale factors (like 2 or 4) alright, but 3 appears to get best results across the board. Added benefit of the anti-aliasing is that diagonal lines no longer look as jagged as with the previous script version.
Any feedback or suggestions? I still need to write/update map view generation and upload scripts, so it'll be a while before I start rolling out maptabs in DM/CTF map articles. --Xymph (talk) 11:10, 5 September 2018 (CDT)