Project:General Discussions

This page is meant to be a hub for general discussions about this wiki, its use and its editing. Feel free to use this page to note wiki problems and leave messages for the community. Feel free to add/revise sections as necessary and move items that have been completed to the "Completed" section below.

Global Replacement Request
A spot to capture global replacement requests:
 * Update testing/entry template to always include "tester=" field. Kolano (talk) 01:36, 29 May 2015 (CEST)

Titles without GameINI entries vs Rating
Okay, I'll get straight to the point. I don't think that problems caused due incorrect configuration (e.g. a non-default setting or a title with missing GameINI) should affect the rating of such title. Since we have established that entries under Problems section do affect the rating, my proposal is moving those entries related to issues that happen due incorrect configuration to the Emulation Information (as it's caused due bad config, not due an inaccuracy of the emulator) and leave the Problems section just for problems that will happen regardless of the settings (these are the real problems to my understanding). Given how the wiki evolved those years this feel natural to me (e.g. we already do the same with entries of enhancements that causes issues being on Enhancements instead of the Problems section) and I think it would at least alleviate the issues we have with the current rating system. Some "real-world" examples of what I'm proposing can be seen in Amazon Instant Video Channel, Crunchyroll Channel, Hulu Plus Channel, YouTube Channel and Super Smash Bros. Melee. - mbc07 (talk) 01:56, 13 March 2017 (CET)


 * I'm fairly strongly opposed to this handling. In most cases we have options (i.e. the gameINIs) to resolve configuration related issues out of the box. For the most part these should be simple changes to implement, we have even tried to make this easier by providing explicit lists of titles requiring each config change. I can probably pump out some pages to reference things by the GameIDs to make it even easier if that will help.
 * It's seems preferable for games to be emulated appropriately by default than to rely on people looking up and re-configuring things for each title they want to emulate. The majority of titles who's ratings are impacted by these things can be corrected by GameINI updates. I'm unclear it's inappropriate to push for such, as for the most part such updates seem simple to implement (I don't have time to look into it now, but would be happy to do so give a few months).
 * That said, there are a limited number of titles where accurate emulation results in undesirable performance impacts, Smash Bro's for instance. I'd be more comfortable with elevating specific issues like that to Emulation Information. At the same time, in such cases, I'd hope for specific acknowledgement that a recognized issue exists, and is being ignored by developers for performance reasons.
 * In some cases GameIni settings may not exist, which is a separate problem. Though I think we have fairly good parity with critical settings and the ini's now.
 * Kolano (talk) 06:08, 13 March 2017 (CET)


 * To be more specific, I agree the GameINIs of affected titles must be updated to automatically handle the needed settings instead of the user needing to manually adjust those settings, I just don't agree those config-related problems should affect the title rating in the meantime we have a problem entry here in the wiki waiting to be crossed when the INI get updated, hence why I'm proposing moving them to Emulation Information, which isn't considered when assigning a rating.
 * We would still cross those entries when the INI get updated and purge them out when a new stable version is released, and for cases such as Super Smash Bros Melee/Brawl (EFB2RAM/Real XFB) the related entry would just live here in the Emulation Information indefinitely.
 * It would also finally put some consistency on our compatibility charts, for example, we have nearly 70% of titles with a "Playable" rating but I bet at least 20% of those already are "Perfect" for a long time but are "stuck" at the 4 stars rating anyway just because the user needs to manually adjust something with some mouse clicks in the meantime the GameINI doesn't get updated or in cases the GameINI probably never will be updated (such as Smash Bros).
 * TL;DR that's just another issue with our stone-age rating system that's bugging me for a long time and I strongly think this change would greatly improve the consistency of the current system without requiring drastic changes on the wiki, especially after the previous attempts which didn't go anywhere (e.g. the relabeling of the ratings from MayImilae, the 3-star rating from myself or that "blue stars" thing from Lucario) - mbc07 (talk) 06:37, 16 March 2017 (CET)
 * We haven't even discussed about "blue stars" yet. I've been working on it but I can't seem to get it working the way I want it to yet, hence why I didn't feel like starting a discussion about it yet. The blue stars was supposed to avoid misleading the users thinking there'd be no (or not as much) issues with default settings. Users will quickly notice its color before they even look at how many stars there are and being misled. Lucario (talk) 00:16, 18 March 2017 (CET)
 * 5% of the population has some form of color blindness... - MayImilae (talk) 03:48, 24 March 2017 (CET)
 * Now that you mention it, I've ran blue and yellow stars into several color blind simulators and I was still able to distringuish between them just fine. Also there is new text "(configured)" appended next to rating text that'll take readers to the Configuration section to see how it ended up perfect or having lesser issues. (In case you were out of loop, notice that Super Smash Bros. Melee/sandbox has blue stars, it's static ATM) If a color blind user is still unable to distinguish between the blue and yellow stars he can always look at whether there is text "(configured)" appended next to rating text or not. Lucario (talk) 07:20, 24 March 2017 (CET)


 * Side note, since it seems you've been doing some Channel testing. Can you fill in the missing Channel GameIDs, mbc07?
 * That's already on my list, I got busy with other stuff but I'll fill them soon (probably before the end of this month). On another side note, from a quick look, channel IDs seems to lack a publisher code, being only the first four characters. Is that normal? - mbc07 (talk) 06:37, 16 March 2017 (CET)
 * And yeah, I'm not sure, but from looking elsewhere it seems "01" may be used for Channels rather than assigning them to their actual publishers.


 * I still feel it will be bad for users to see titles rated as 5 star, play the game and face errors, and then fight us here on the perfect rating. I'd much prefer to focus on actually getting the INI updates made than lots of revisions here to account for things differently. Kolano (talk) 21:02, 17 March 2017 (CET)


 * Ack! Sorry for replying so late, I've been super busy IRL! So um... I'm opposed. If a user loads up a game, and encounters a problem, they should find the solution in the problems section (or the emulation section if it is a game bug or something), whether it is their fault or not. Remember, I support keeping problems that can still occur if the graphics config is opened (suitably labeled) - what's most important to me is informing users. - MayImilae (talk) 03:48, 24 March 2017 (CET)

Problems / Global Problems Merging
I have an idea, we can inherit contents from Global Problems section into Problems section then add "(global problem)" after the problem name. After previewing in game page and looked back at the game page, I started to feel that Global Problems section is one section too many, this gives more appeal to this idea. How do you like this idea? Lucario (talk) 21:03, 24 November 2016 (CET)
 * No. Those sections are intentionally left separated for a reason (only VC pages have it and they are shown if, and only if, there are global problems affecting all Virtual Console titles in Dolphin or all Virtual Console titles of that specific platform). Another reason is that they can't (and shouldn't) be edited here, hence the separation. - mbc07 (talk) 00:44, 25 November 2016 (CET)
 * I figured, but should be possible to call appropriate Template:GlobalProblems| inside Problems template using the matching system type the game page is using. I can't figure how to retrieve system type from Category: from game page which would've left least editable to the general editors & pure automatic if implemented correctly. If that's not possible, maybe try make use of |type= parameter... IDK. Last resort is to duplicate Template:Problems codes into Template:GlobalProblems| templates under a new template name and don't let VC pages have Template:Problems. Lucario (talk) 22:52, 25 November 2016 (CET)
 * The point isn't whether it's possible or not (it certainly is), the point is that I see no reason to merge those sections nor I think they should be merged. The current separation is already clear enough (Global problems edited at a specific place which reflects on all game pages of that platform vs Problems specific to that game page) and works well enough. Doing what you're suggesting would just require extra work, would make problems editing more confusing and wouldn't provide any advantage compared to the current setup. If all you want is to take advantage of accurately problem state tracking in the categories (which is the main advantage of Problems BTW) it can be ported directly to GlobalProblems (and I already have plans to do so). Just don't expect both sections being merged because I won't do that, at least not until you provide me a good enough benefit that we'll have if they get merged, compared to the current setup (until now, you haven't provided any). - mbc07 (talk) 02:59, 26 November 2016 (CET)


 * I thought you already knew it will benefit of not leaving the Problems section empty or writing some awkward sentence to make it not empty. I didn't think it will require more work from us once the global problems was merged into Problems template. The game list will use familiar Global Problem template while Problems template will call appropriate Global Problem template into the game page. And since you said it's bit confusing, perhaps use comment tags suggesting a way to edit the global problem? If you think this benefit isn't enough then never mind. I'm cool with what we have now. Lucario (talk) 22:37, 26 November 2016 (CET)


 * One of the concerns raised above was in the number of page sections, the merge would reduce the page section count by 1 which might be good. Since the global problems can't be directly edited anyway, I'm not clear there's a good reason to maintain a separate heading for it. Actually it might be an advantage to get rid it, since that way there'd be a more direct path to seeing commentary on how Global problems work. Kolano (talk) 06:10, 27 November 2016 (CET)


 * It would reduce the page section count by one only if it is a Virtual Console page and if there are entries in the global problems template of that specific VC platform. The call to Global Problems already have a comment tag pointing to the correct place to edit that and being a separate section makes very clear it's not on the game page that those entries are located, plus it actually makes the differences between the Global and "local" Problems section very clear (global problems don't have an [edit] button at all and the entries are located somewhere else, "local" problems have the [edit] button next to the heading and all displayed entries are right there so you can edit them directly). Also, reworking the Problems template to accommodate both Global and "local" problems entries under the same section isn't as simple as it sounds (it would actually require a lot of work, especially when you start to think about things like keeping both local and global entries "sorted" properly -- active local, active global, fixed local, fixed global, -- and that it's just one point, put in the variables manipulation or the new RegExp queries that would be needed and it just becomes even worse). Besides that, if both global and local problems were on the same section, even having a comment tag there would be more confusing and inconsistent than the current setup (e.g. an editor seeing entries that aren't there popping on the page or clicking on edit just to realize an entry that is displayed on the page that they wanted to change isn't located there).
 * So, like I said, I still prefer to rewrite that "awkward sentence" a thousand of times until it gets acceptable on those VC pages with no "local" problems but with Global Problems than doing all that hard work just for the sake of merging both sections in a single one, especially considering that only a small subset of pages (VC titles) would be affected while it would also make the Problems section of those VC pages inconsistent with how this same section works everywhere else. The work required is simply not worth as there aren't any real benefits of doing that. By the way, if there aren't any other points besides this one, I'll probably start implementing Problems on the pages sometime during this week. - mbc07 (talk) 06:52, 27 November 2016 (CET)


 * You've got really good point about sorting active and fixed problems and the global problem entries will always be in top before the local problem entries. Might be overcome with calling global problems template twice and regex to filter out "active" then "fixed" using same template call at different time with slightly different regex codes into top and bottom beyond list of local issues. This will probably require a full duplication of itself with slightly different regex with regex mainly for renaming global problem headings with "(global problem)" added in. I see that you're making a big deal out of the edit button used to distinguish things and how the global problem entries being merged into the Problems template are going to confuse the editors. The global problems, after merged into the same section as other local problems, can still be identified by looking for "(global problem)" in the heading of the issue, and the comment tags will point editors to the location where global problem entries can be edited at, if they plan to edit them. How is this any more confused?
 * I don't know well with regex, so I may be wrong with how feasible it's gonna be to handle global problem entries into top and bottom and edit each heading with "(global problem)" added in. Lucario (talk) 05:52, 28 November 2016 (CET)


 * Saw two more benefits for that, but I could be dumbass thinking these will work: adds Category:Pages with missing VC system using $ifpageincat: (is this it?) against Category:Virtual Console games (to skip the job on the non-VC game pages) then #if: on top of #ifpageincat: against VC & call matching global problem template, if returns nothing... assuming I'm correct... then a page doesn't have a VC system mentioned. 2nd benefit is the opportunity to label slashed and whatnot global problems with appropriate active/fixed categories along with "(global problem)" during regex search n replace. Lucario (talk) 20:42, 28 November 2016 (CET)


 * Okay, before continuing, let's clear some points:


 * * Calling GlobalProblems inside Problems and doing RegExp on their entries: I might have overlooked but that seems exactly what you did in the recent changes to Problems (which I reverted by the way, use a template sandbox or something similar for that). It's useless, just adds processing overhead server-side and won't provide any benefit because Global Problems will never show different content on a page other than what's on their variables, so doing the query directly in GlobalProblems (which as I said it's on my schedule) it's way faster since it's only 10 "Global Problems" pages compared to doing the query on all VC titles pages, while providing exactly the same result.


 * * Category:Pages with missing VC system: I'm neutral on this one, it *might* be of some use but I'm not sure either since as far as I could check all VC titles pages we currently have already are correctly categorized (and since it's only a small subset of pages, it isn't hard to keep them properly categorized), not to mention #ifpageincat is also an expensive parser function, I would avoid using it.


 * Now, back to the main subject, I messed around in a page with your suggested "(global problem)" postfix on the headings of Global Problems and I found the result fugly. You also brought me another point: since the best way (at least performance-wise) of querying the entries in Global Problems and properly categorising the page accordingly would be directly in the base template rather than calling GlobalProblems or its variables inside Problems, that's actually another reason to keep the sections separated: Problems would need yet another complex filtering to avoid appling the RegExp queries twice on the global problems, while not affecting entries of local problems. TL;DR you still hadn't convinced me, my vote for merging both Global Problems and Problems into a single section still is a big no (especially now with the proposed postfixes on headings) and my thoughts remain the same: merging both sections is way harder than it seems and there's no real benefits to justify the huge amount of work that would be required to properly achieve that. In fact, it looks like you're trying to "fix" something which is not broken. If I were you I would concentrate my ideas on a better message for the empty Problems section when the page have active Global Problems instead, which seems to be main reason you came up with that proposal as far as I can tell. - mbc07 (talk) 03:06, 29 November 2016 (CET)


 * As I feared, it seems the template overheads for global problem may not be good for performance on server side as majority of game pages aren't even VC. What about the other way around: global problem template to call problems template instead (in new template name like Template:ProblemsVC) so the overheads will not be there in non-VC game pages? Well, let's put this on hold, we should discuss on how the page should actually look, since you dislike having postfix "(global problem)" in problem entry headings, then let's worry about the complexity of template overheads later (I also realized, we can just forget about Category:Pages with missing VC system and other template overhead redundancies because there aren't as many VC pages & only 10 global problem templates), and worry on silly template name the least. I still want to merge the global problems into problems section to reduce number of sections and get rid of "awkward sentence". I also am on the same side as yours on silly heading postfixes though I still think it's better than global problems + problems section with awkward sentence personally. We'll need more opinion on this...


 * I'm fine with Problem template going official now. Lucario (talk) 23:16, 29 November 2016 (CET)

MD5 / GameID capture
We should probably capture/list the GameIDs and valid MD5s for games to aid in avoiding issues related to bad dumps, and providing accurate regional/version release information. There are a few things we'd need to work out for such though:
 * A source of info, Redump.org lists valid MD5's for GC discs and GameTDB provided them for GC discs and a subset of Wii discs (though it's unclear of the source of the Wii ones or if they can be confirmed as valid).
 * How to capture the data: We'll likely need some new templates / data structures to do so.

Adding this section for future discussion so we can hopefully eventually move forward with such. Kolano (talk) 07:58, 29 September 2014 (CEST)

I'm in with that. I suggest implementing this in a similar way to the Ratings, that way we can reuse the MD5 hashes across wiki templates. Something like Template:MD5/Sample_Game with the hash in plain text may do the trick. Not sure where we could get MD5 for Wii games, GameTDB has a small number of hashes for Wii games - mbc07 (talk)


 * Yeah, that came up in the discussion on IRC last night. We can get a near complete set of them for GC titles from Redump.org if needed though GameTDB likely has the same set for those, but those for Wii titles seem to be less available (and possibly unconfirmed where they do exist). Kolano (talk) 00:22, 30 September 2014 (CEST)

I'm a little worried about this, to be honest. We have no way to confirm MD5s, so essentially we'll be relying on our sources, which are incomplete and may be wrong themselves. I'm not against the idea, just, I wish there was a way to be sure. A Wii homebrew program or something to calculate MD5s to build from on our own perhaps? I don't know. Any time we put up information that can't be verified, it makes me nervous. It could be wrong and we'd neeeever know it. - MayImilae (talk) 08:05, 2 October 2014 (CEST)


 * If this gets implemented, which I'm for, could we record if it's a SL or DL disc as well? Zephyrsurfer (talk) 10:18, 12 November 2014 (CET)

OK, so I found today that although there is no dat file publicly available indexing Wii discs at this time, Redump.org does have one. Apparently the situation is that it's only being distributed to registered dumpers. I was able to find copies of it from early in 2014 via this set of archives. In any case that's probably as close as we'll come to known "valid" ids, and we probably should try to find a more up to date copy. Kolano (talk) 18:08, 21 November 2014 (CET)

Should the infobox template have a section for known good MD5 checksums for each game? Dolphin has an MD5 evaluator function built-in the properties window of the game you right-click on. Let's say for Super Mario Sunshine, the template lists each unique checksum for each region; one for NTSC-J, NTSC-U, and PAL when you dump them with CleanRip. CleanRip has gc.dat and wii.dat files that is really an XML. The Wiki redirects to the game page through game IDs so a custom script bot could easily automatically fill in the thousands of MD5 checksums using the XML attributes found in the gc.dat and wii.dat files. This would be good to ward off bug reports that rely on bad dumps of games with bug reports that rely on good dumps of games. --Wildgoosespeeder (talk) 08:52, 1 May 2015 (CEST)


 * So it seams we may have a source for MD5s. Kolano (talk) 17:32, 1 May 2015 (CEST)
 * Oh! Didn't see this discussion. I even searched for MD5 before posting my idea! --Wildgoosespeeder (talk) 23:34, 1 May 2015 (CEST)
 * Further digging into ripping Wii discs, I found out that some games are not in the XML, like Sonic & Sega All-Stars Racing and The Sims 3. I could not find their generated MD5 values in the XML or their titles. --Wildgoosespeeder (talk) 04:45, 10 May 2015 (CEST)

Dolphin itself now directly confirms GameCube (and eventually Wii) IDs against Redump's public IDs as of. That's a pretty good stamp of approval for Redump, but also kind of eliminates the need to keep MD5s here at the same time. Just adding this as an update. - Xerxes (talk) 02:00, 25 October 2019 (CEST)

Error with Slash in Search
Using a forward slash in a search term (i.e. "NA/EU") results in a long set of Wiki errors... "Warning: preg_match [function.preg-match]: Unknown modifier ')' in /home/dolphin-emu/apps/wiki/includes/search/SearchEngine.php on line 1402" Kolano (talk) 22:01, 28 August 2013 (CEST)

Now it's... Warning: preg_match: Unknown modifier ')' in /home/dolphin-emu/apps/wiki/includes/search/SearchHighlighter.php on line 512 ...but this still occurs. Kolano (talk) 07:04, 13 March 2017 (CET)

Consider using TitleIDs for Open Issue Search
Instead of using the game's title to look for open issues, it would be better to use the all possible TitleIDs affiliated with the game. By using the TitleID, the accuracy of the search is increased to game specific issues. It removes the chance of mixing issues from different games.

For example: Super Mario Galaxy

Original Search:

https://bugs.dolphin-emu.org/projects/emulator/search?q=Super+Mario+Galaxy&open_issues=1

Proposed Search:

https://bugs.dolphin-emu.org/projects/emulator/search?q=RMGP01+RMGK01+RMGJ01+RMGE01+RMGR01+RMGC01&all_words=&open_issues=1

Techydude3 (talk) 20:45, 29 May 2020 (CEST)


 * Sounds reasonable, however, from a quick look, it doesn't seem that trivial to implement since the Game IDs come directly from the DPL extension and I'm not that experienced with its usage... - mbc07 (talk) 21:51, 29 May 2020 (CEST)


 * Nah it shouldn't be a big deal to do. Sorry for ninja-ing you but inspired by this idea right after you said that I changed the ID system to save the results of the DPL to a variable, allowing for this change to be made by regexing the variable. As a benefit, we also get Category:Pages with no GameIDs which we never had before. It'll take me a bit to do the regexes though since I'm terrible with them... - Xerxes (talk) 22:12, 29 May 2020 (CEST)


 * Done. It uses IDs for the issue tracker search on pages that have IDs, and on pages that don't have IDs, it uses the page title. - Xerxes (talk) 00:33, 30 May 2020 (CEST)


 * Thanks! I appreciate your assistance.- Techydude3 (talk) 01:39, 30 May 2020 (CEST)


 * It is fairly common for the GameIDs to be missing from issues that are ill-reported. We should probably search for the game's name in addition to the GameIDs to get those cases. - MayImilae (talk) 13:36, 3 June 2020 (CEST)


 * Sure, that makes sense. I'll have it do both. My reasoning was that people would know to use the issue tracker for the game's title intuitively but not necessarily know how to search the IDs, so users would try searching the title on their own, but just searching for both to begin with makes more sense. - Xerxes (talk) 20:10, 3 June 2020 (CEST)

Recent Discussions
Below is listed of recently concluded discussions. You can search the archive for what was discussed since General Discussions page was created.

Proposed expansion for Wii GameIDs
The ID6 format used by GameCube GameIDs fails to properly represent all of the information that a full Wii TMD contains. As an example, the ID SVTEXS is assumed to represent all the game identifiable information for BIT.TRIP Complete that can be guaranteed to exist. However, an actually complete ID would be 00010000535654455853r00. This presents the full 18 hex digit Title ID, as well as the title version information from the TMD file. The "r" separator between the full ID and the title version is already in use by one of the GameINIs that ship with Dolphin, which is why I'm suggesting it be used. Default GameINI for 0000000100000002r1, known as the Wii Startup Menu on the wiki. Properly representing IDs in this format will allow us to almost guarantee that we send users to the correct page for the Title they're trying to get information on. Including the Title Version allows for proper distinction when multiple revisions of a Title need their own pages, IE: Wii Menu and Wii Startup Menu. Using hexadecimal digits instead of trying to represent them as ASCII GameIDs allows for displaying the Title IDs for the WADs found within the Wii Backup Disc properly. Instead of trying to figure out to make a page titled kVß.02 we could just make one named 000100006b56df1e0002r00. For a less specific usage case, adding TitleIDs for any Wii DLC will be impossible without using this format. All of their TitleIDs start with a lowercase letter, which is not allowed for MediaWiki pages. - PowerKitten (talk) 19:09, 9 October 2017 (CEST)


 * You should consider first the implications that this would have on Dolphin. As much as I like the function of this wiki as an archive, the first and most important goal should be making everything consistent with how Dolphin handles it. Right now, Dolphin gives all IDs as six character IDs. This is used not just for the right click wiki link function, but also is used on the game information display page in Dolphin, used in issue reports on the issue tracker, and used for Dolphin's GameINI system for automatically changing settings which cause issues (from reading, that one ID you bring up only uses the extended format to avoid the automatic settings affecting other versions of the menu). If the standard was going to be changed in one place, it would follow that it should also be changed in the others. We're talking about multiple different codebases/databases full of the shorter format that would need to be changed. Not that it couldn't be done, there's people much smarter than me that could plan out and write programs to transition everything over, but I'm thinking about cost/benefit. In a perfect world, we'd just have a full archive of all GameCube IDs and Wii TMDs sitting on our laps and we could easily just swap everything over like it's nothing, but reality's not like that sadly. I'm not really sure how you plan to acquire these format of IDs for retail Wii games for example without actually buying the game, then dumping it, then looking for the TMD in the disc's filesystem, unless retail games' TMDs can also be accessed from Nintendo's servers?


 * Also, as far as I know there's never been any effort at all to document add-on DLC here, so there's no infrastructure or standards currently in place for that. If you wanted to make it, nobody's stopping you, but again, it should be framed in the perspective of how Dolphin handles DLC (which I have no knowledge about since I don't particularly like the Wii). - Xerxes (talk) 20:27, 9 October 2017 (CEST)


 * Fair enough, I'll go ahead and cancel this proposal. It wouldn't be worth the work involved. The other problem is with GameCube games, as their BNRs only use the ID6 format. Meanwhile, TMDs are a required part of how the Wii reads Wii games, so each partition of a Wii game disc has a TMD due to that. I'd have to buy and dump every Wii game to verify the full IDs, which would be a massive undertaking. Thanks for humoring me, Xerxes. - PowerKitten (talk) 16:13, 10 October 2017 (CEST)

Gameplay Screenshots section worth staying?
I think it'd be more appropriate to take them to HD screenshot thread in Dolphin forum. By getting rid of it from here, it'd be easier to distinguish between them and the emulation bug images here, because they wouldn't be anywhere here in the first place, and there are only few screenshots so it'd be much less of a loss compared to trying to get rid of gameplay videos. There seems not much going for HD gameplay screenshots here. There are lot of "Gameplay Screenshots" sections with nothing under that bothered me. I don't think anyone will care if it's gone along with those that contain screenshots. Do you agree? Lucario (talk) 23:59, 25 February 2017 (CET)
 * I'm fine with screenshots leaving! The wiki was never good at handling them. - MayImilae (talk) 04:10, 26 February 2017 (CET)
 * Yeah, Wiki doesn't seem a good place for users' gameplay screenshots. Lucario (talk) 23:26, 1 March 2017 (CET)
 * Agreed that they haven't gotten enough attention to be worth preserving. Kolano (talk) 04:26, 26 February 2017 (CET)
 * That's actually something I wanted to do for a while as we probably can count on the fingers the number of pages with Gameplay Screenshots. Dropping this section would also allow me cleaning Image a bit... - mbc07 (talk) 04:22, 27 February 2017 (CET)
 * Okay, so everyone agrees that that section should go. I'll leave them up to you guys to delete them since I don't think I have rights to do so myself. Lucario (talk) 23:26, 1 March 2017 (CET)
 * All the images to purge should be under Category:Screenshots, and I presume the mass search-n-replace can purge the sections fairly easily. I haven't gotten familiarized with the new one we swapped to yet though. Kolano (talk) 01:05, 2 March 2017 (CET)
 * I can take care of that but, can you guys wait until the weekend? I would like to clean up image too, it has a special case coded for handling Gameplay Screenshots section... - mbc07 (talk) 02:39, 2 March 2017 (CET)


 * It's done. For anyone curious, at the time of the mass edits we had 3139 game pages but only 271 of them had the "Gameplay Screenshots" section. I've also noticed that some screenshots used on that section were also linked on other places, so I didn't delete any of those files and wouldn't recommend doing so until we can reliably figure out what pictures are still in use. - mbc07 (talk) 07:49, 4 March 2017 (CET)


 * Purged out the unused images. Kolano (talk) 06:52, 13 March 2017 (CET)