Project:General Discussions

From Dolphin Emulator Wiki
Revision as of 04:10, 26 February 2017 by MayImilae (talk | contribs) (Gameplay Screenshots section worth staying?)
Jump to: navigation, search

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.

Open Discussions

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. - MaJoR (talk) 04:10, 26 February 2017 (CET)

Recent changes Style?

Has something changed recently to effect the Recent changes page? It currently shows up without styles for me. Kolano (talk) 00:15, 7 December 2016 (CET)

Problems section automation

Okay, that's something that bothered me for a long time but I couldn't find a "good" way to address, at least until now. Basically, the Problems section exists on all game pages, but on games without any problem, it's just an empty section without any information (that bothers me), and when it have problems it's not always correctly flagged in Category:Pages with active problems or Category:Pages with fixed problems because it relies on {{issue}} or {{s}} being called somewhere in the page, which isn't always the case.

After some tinkering, I think I found a good way to address those points without making things complicated. It's actually using the new {{Problems}} template I just made. Similar to {{Config}}, it takes the input then handle it accordingly. I also made the usage as simple as possible, take the example below (this is how the problems section looks like nowadays):

== Problems ==
=== Problem 1 ===
Game XXX has an issue when using save states, which will corrupt your save file.

{{Problems/VP6 Videos}}

=== {{s}}Fixed Problem 2{{/s}} ===
Game XXX will display corrupted graphics when using EFB2Tex, use EFB2RAM to avoid that. Fixed in {{revision|5.0-1000}}.

To use {{Problems}}, the modification in the page is pretty small. For example, that's how it would look:

== Problems ==

=== Problem 1 ===
Game XXX has an issue when using save states, which will corrupt your save file.

{{Problems/VP6 Videos}}

=== <s>Fixed Problem 2</s> ===
Game XXX will display corrupted graphics when using EFB2Tex, use EFB2RAM to avoid that. Fixed in {{revision|5.0-1000}}.


The call to {{Problems}} should be added into every game page (and well, we have MassEditRegex in our favour) and it has the following advantages:

  • It deprecates {{s}} and {{/s}} and also the workaround currently implemented in {{issue}} templates. It also somewhat achieves the same goals of the experimental {{Active}} and {{Fixed}} templates, so, 4 less templates to maintain and one workaround dropped.
  • Similar to Config section, it provides a nice "Currently there's no known problems with this game." text on pages without any problem entries (that's something I always wanted to have).
  • It accurately flags pages under Category:Pages with active problems or Category:Pages with fixed problems without depending of external templates and correctly track even active problems without an issue link (something we currently don't track).
  • It also flags pages with potentially misformatted entries (e.g. the problems section is not empty and did not get flagged in any of the active or fixed problems categories).
  • From my preliminary testing, it works without issues with any of the {{Problems}} subtemplates as well.
  • You can also use the type= parameter to better reflect the page type (e.g. channel pages). This parameter is optional and works exactly like the type= parameter from {{Config}}.

And well, there's a single disadvantage, but given the benefits I think it's perfectly doable: the "[edit]" button disappears from the individual entries, but you can still find it under the main "Problems" section. So, given the benefits, I almost started implementing this everywhere, but it's a somewhat big change, so I would like to hear any thoughts you guys might have before starting (especially from User:Kolano and User:MaJoR). - Jhonn (talk) 07:56, 19 November 2016 (CET)

The missing edit buttons are deficit. That will likely require looking at each specific Problem edit to tell what was revised (i.e. since section titles won't appear in the Recent Changes list). I'm supportive of this though, since I'd like to see the Active Problems functionality restored. Kolano (talk) 20:09, 19 November 2016 (CET)
Going to try it out on a few pages so we can get a feel for how it works, presuming it works well enough to not bother with sandbox pages...
...Price is Right shows it successfully adding to Category:Pages with active problems category without an embedded {{Issue}}. Would be nice if some extra parsing could allow flagging such (i.e. problems /wo issues).
Kolano (talk) 02:21, 20 November 2016 (CET)
Do we want to pull the Problems heading into the template as well. We already do so for the Problems subtemplates. Kolano (talk) 03:01, 20 November 2016 (CET)
I particularly don't. I intentionally left the main "Problems" heading out of the template so we can get the "[edit]" button on it at least (e.g. similar to config template). If we insert it into the template the button will be gone and so edits in the problems section would be less obvious on Special:RecentChanges, outsiders might not understand why the other sections have edit buttons while Problems doesn't, etc etc. Regarding flagging pages with active problems but without issues, I think it's doable by using #varfinal, I'll try to get that working Seems more tricky than I thought, but I think I can still find a way to do this by messing with RegExp capture groups, stay tuned - Jhonn (talk) 04:09, 20 November 2016 (CET)
I agree with Jhonn, it'd be less consistent with other heading 2 sections (== text ==) and thus will confuse the editors. I'm perfectly fine with heading 3 sections (=== text ===) to not have edit button, that will be great for edit summary too, we don't need to see some obscure problem name but something we're very familiarized with, "Problems". Lucario (talk) 05:40, 20 November 2016 (CET)
Compared to Template:Active and Template:Fixed, this will provide text that there's no known problems to the Problems section with empty contents. It also doesn't require use the same templates constantly for the multiple problems. There are downsides against Template:Problems too but I'm gonna refrain from saying it. Lucario (talk) 05:40, 20 November 2016 (CET)

Okay, it's done. Flagging pages with active problems but without issue links was harder than I though but it's now implemented. Basically it does a RegExp query to find how many active problems the page has (it does that by "counting" level 3 headings without <s></s>) and after that it loops through the text of each "active" heading it found earlier querying for "[<number>]" (it wasn't possible to search for {{issue}} calls directly because the template was parsed before the RegExp query). Although it currently does that lookup only on active problems, I left in the template some "base" code enabling us to do the same with fixed problems as well, if we need (maybe tagging pages with fixed problems without a revision link? Not sure if that is useful but it's that kind of thing which is possible to do). TL;DR, it outputs a nice text saying there are no problems if the section is empty and accurately flag pages under Category:Pages with active problems, Category:Pages with fixed problems, Category:Pages with active problems missing issue links or Category:Pages with misformatted problems without needing additional templates like {{s}}, {{/s}}, {{active}} and {{fixed}} or the workaround in {{issue}}. If there's nothing more you guys want to ask or to add on {{Problems}}, I'll start implementing it on all pages... - Jhonn (talk) 06:40, 23 November 2016 (CET)

One more thing, do you think we should do something with Global Problems section as well? It'd be abnormal to read the Problems template saying there's no problems with a game although there is one or several right under Global Problems section. If we're gonna integrate the Global Problems section into this Problems template we'd have to include the heading 2 section "Problems" too, this will sacrifice the Edit button however. I'll go for sentence rewrite route. Perhaps let Global Problems template tell the Problems template (using Extension:Variables "#vardefine:" and "#var:") there are problems under it and use alternate sentence. Or we shouldn't mind about it too much? Lucario (talk) 07:07, 23 November 2016 (CET)
It should be possible to have the Global Problems template output a variable we can pick up on in the Problems template to account for that. Kolano (talk) 09:44, 23 November 2016 (CET)
Done. Refer to Kirby's Adventure, Super Ghouls 'n Ghosts or Super Mario RPG: Legend of the Seven Stars to see {{Problems}} behavior on different scenarios when used on VC pages. Is there anything else you guys want? - Jhonn (talk) 16:39, 24 November 2016 (CET)
I'm not comfortable with problem template saying "Excluding Global Problems listed above, ..." because the compatibility rating is supposed to take problems from Global Problems and Problems sections into account and if problem template tells that there are no problems besides global problems, it seems to tell that compatibility rating should do the same. Lucario (talk) 20:32, 24 November 2016 (CET)
Global Problems are (and always were) taken into consideration when assigning a rating, and as I said in the edit summary, the message shown here can be tweaked. BTW, I'm not sure if the issue tracker should be linked here either, AFAIK the devs intentionally made it not too evident (not even the main website links to it after all) - Jhonn (talk) 00:44, 25 November 2016 (CET)
I see. The sentence that points to Dolphin's issue tracker was actually just filler to make the section don't look empty. :P I'm not comfortable with it saying something like "excluding Global Problems above". Lucario (talk) 22:52, 25 November 2016 (CET)
Just noticed the unused parameter "Wikipedia". This has been overlooked when I was copy/pasting from Template:Infobox VG. I thought I'd like to point that out. Also, would it be better if we renamed the category "Active Problems" to "Ongoing Problems"? Lucario (talk) 00:09, 2 December 2016 (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. - Jhonn (talk) 00:44, 25 November 2016 (CET)
I figured, but should be possible to call appropriate Template:GlobalProblems|<system> inside Problems template using the matching system type the game page is using. I can't figure how to retrieve system type from Category:<system> 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|<system> 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). - Jhonn (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. - Jhonn (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. - Jhonn (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)

Category Intersection Search

it seems that there is no option for searching pages that are a part of two categories or more, at once. if you see the last section of this mediawiki page then you will find the various options for doing so. however, dolphin wiki's special:search page does not work with with, for example:

incategory:Multiplayer_(Game_mode) incategory:Fighting_(Genre)

or even if just using one of the above. so i propose that if fixing that is not simple, that the extension found in the mediawiki article above, is installed. i, personally, would find it extremely useful, and it seems it would take only minutes to install.

Drmario (talk) 17:07, 12 September 2016 (CEST)

Thanks for the heads-up. Since this is something potentially useful, I requested to one of the guys who maintain the website to install this extension, but he's away and so it will take some days until he can install it to us. In the mean time, I think you can use the DPL3 extension we have on this wiki to generate a report of pages which intersect as workaround. Kolano probably can help you more with its usage (you can also check any of the Problems templates for usage examples as they also uses DPL3 extension). - Jhonn (talk) 21:24, 12 September 2016 (CEST)
thank you for the fast reply. i noticed it the next day, but decided i'd see what happens next, as i wasn't sure how simple dynamicpagelist3 would be. but, i tried it today and it's relatively straightforward, but only after having spent 40 minutes with it - i'm not the first person to say the manual is a bit confusing, as it seems it is a very complex extension, with a tonne of options. i added a few much simpler examples to the manual, based on what i wanted to do. but i think other users with the same problem might appreciate the more specific GUI multi-category search extension on the mediawiki, if they are not as comfortable with wikicode, or if they don't find this 'general discussions' page. provided it doesn't cost much overhead, of course.
Drmario (talk) 14:30, 17 September 2016 (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.

5.0 announcement

  • What needs to be done here in context of the Wiki apart from the 'Progress continues' message being updated?
    • Updates to the {{Revision}} and {{VersionRevision}} templates. I think most of the baseline stuff is there, but the specific release # to associate with 5.0 still needs to be set, and some other tweaks may be needed. (done, I think)
    • Purging of 4.0 resolved issues (done)
  • Feature differences between 4.0 stable and 5.0 that might require some page updates
    • There should be few, if any, of these as we have accounted for development releases throughout the 4.0 cycle.

5.0 Release time is basically... right now! Me and JMC are busy getting everything ready on the blog side. Someone else will need to get things ready here. The current goal is Sunday, and all signs are pointing to us making it, so we don't have a lot of time! - MaJoR (talk) 22:07, 14 June 2016 (CEST)

Oh, one minor note. About issues that can still happen when opening the graphics configuration menu - I'd really like for them to stay. Right now some are marked as fixed and others are not, so if we purge all fixed issues right now it will be a mess... What do you guys think we should do we these? Precedent is all over the place right now! - MaJoR (talk) 22:10, 14 June 2016 (CEST)
So, what's the plan? Wait until 5.0 is out officially to start purging crossed entries? Or start right now? I have some free time during this week, so I can help with the purging... - Jhonn (talk) 05:05, 15 June 2016 (CEST)
Weren't we going to automate it? - MaJoR (talk) 07:11, 15 June 2016 (CEST)
Since we isolated crossed entries on a separate category, I'm pretty sure we can do that with some RegExp trickery. But then, some issues that can still happen when opening the graphics configuration window would be purged too (the ones that were crossed). If we're really going to automate it, we should go through the pages manually to check that case you noted before starting... - Jhonn (talk) 08:57, 15 June 2016 (CEST)
Yea, probably best to do it manually so we can check and make sure everything is correct... Or should I say, you should do it, I'm too busy! :P - MaJoR (talk) 04:58, 16 June 2016 (CEST)
I have a big deliverable on a work project on the 20th, so I won't have much time here. Regarding the graphics options issue, I'd kind of prefer to just purge them and then come back with a generic "Opening Config Can Cause Issues" statement on every game that has an INI file. The current coverage seems pretty scattershot. Kolano (talk) 05:13, 16 June 2016 (CEST)
Wouldn't that be hundreds of games though? By having it in the problem it is much more specific, too. - MaJoR (talk) 08:44, 16 June 2016 (CEST)
Well, since we're running out of time, I think I can isolate pages from the Category:Pages with fixed problems that have references to graphics settings with some special searches. After filtering out those pages we could proceed with the mass purge and decide later what to do on the remaining pages with issues that can still happen when opening the graphics configuration menu. I personally think that moving those problems to Emulation Information may be a good deal (similar to the Bounding Box entries on Paper Mario games -- they are already listed on Emulation Information). What do you think? - Jhonn (talk) 02:10, 17 June 2016 (CEST)
That works for me! Thank you for doing it! Sorry I can't be of much help, I'm exhausted from all of this 5.0 prep >_< - MaJoR (talk) 03:08, 17 June 2016 (CEST)

A quick update: by purging the global problems templates, the number of pages with fixed issues dropped to 275 from the previous 700+ (YAY!). Before filtering the crossed issues related to opening graphics settings, I tried to use RegExp to automatically purge the remaining entries (just a test) and... Database Error. Apparently the RegExp sentence is somehow too complex and we can't proceed. I'll contact Parlane to see if he can do something about that, in the worst scenario I'll start purging manually (fortunately the number of pages with crossed entries isn't that big) - Jhonn (talk) 07:01, 18 June 2016 (CEST)

I'm impressed that there is massive drop in number of fixed issues just by purging out from the global problems templates. I may join and do the manual work purging out the fixed problem. Lucario (talk) 07:20, 18 June 2016 (CEST)
Actually that was expected, as the name implies, those global problems are shown in every single Virtual Console game page. And regarding RegExp issue, Parlane is now aware and will look into it soon... - Jhonn (talk) 08:27, 18 June 2016 (CEST)

Another quick update: the Replace Text plugin we were using only supported a limited subset of RegExp functions and that's what was causing the problems. After some discussion with Parlane, Replace Text plugin was dropped and now we have MassEditRegex instead (and as usual, only accessible by admins). MassEditRegex doesn't have the limitations from Replace Text and I'm almost ready, I'll probably start the purging later today. Oh, and I almost forgot, edits made through MassEditRegex are marked as bot edits, so they won't spam Special:RecentChanges unless you explicitly ask it to show bot edits. - Jhonn (talk) 03:13, 20 June 2016 (CEST)

Okay, I pressed the red button, mass edits finished and apparently everything went well. There are some pages that used non-standard formatting and thus didn't get caught on the RegExp query or that have issues that can still happen when opening the graphics configuration menu. Since the number of pages needing special treatment seems very small, I'll take care of them manually now, everything regarding page purging should be done very very soon :) - Jhonn (talk) 04:01, 20 June 2016 (CEST)
A bit uncomfortable with the lack of logging for the new-Regex. It's now impossible for anyone but the implementer to review what happened. I have faith in you Jhnonn, but it makes it impossible for others to review/provide assistance, though I guess it's logged on a per-page basis. Kolano (talk) 05:32, 20 June 2016 (CEST)
The logging is there, but just like the other bots, it's not shown by default. If you mean it's not possible to see what RegExp expression was used, we can establish a guideline to include the expression used in the summary field. For keeping record, I used two expressions, on the same query:
<empty line - placeholder to avoid it being crushed by formatting>
I see now regarding the logging. The one other feature I'll miss was the ability to use the old plug-in's preview as a general regex search. The new one only provides 20 results, so it's not really effective for that purpose. Ah well. Kolano (talk) 00:39, 28 June 2016 (CEST)
... which essentially matched every entry in the format === {{s}}whatever{{/s}} === and then fixed the excess of line breaks left by the first expression. - Jhonn (talk) 05:54, 20 June 2016 (CEST)
Also we shouldn't just transition opening of graphics option issues related to INI conflicts to Emulation Information unedited. We need to indicate the issues now only occur in that case (and only if non-conformant options are set in the graphics config). Would probably be best to set up a new shared Problem template with the general text, that can have specific title issues postfixed to. Kolano (talk) 05:38, 20 June 2016 (CEST)
For now I'm moving them to Emulation Information and tagging them with Category:5.0 cleanup so we can track and make any edits after we discuss how we'll handle those. Also, I'm only moving those entries to emulation information if the game INI already include the settings, otherwise I'm just leaving it in Problems section (uncrossing it if necessary) - Jhonn (talk) 05:54, 20 June 2016 (CEST)
OK, yeah. Just confirmed on IRC that a merge is expected shortly post-5.0 that should resolve the issue (though I'm unclear on the details). Though it will still be there for 5.0 users it may be best to not worry about it too much. Kolano (talk) 05:58, 20 June 2016 (CEST)

I finished the manual review, All pre-5.0 issues were purged from the wiki! At the same time, the number of pages in Category:5.0 cleanup is smaller than I thought, so, if possible, please go through the recent edits to see if I didn't let anything slip out of my reviewing. Now it's just a matter of waiting the official 5.0 announcement to then update {{Revision}} and {{VersionRevision}} templates and the notice message at the top of our wiki and we're done! YAY! - Jhonn (talk) 07:54, 20 June 2016 (CEST)

It's been a while now, have we finished with the review/revision of Category:5.0 cleanup? Kolano (talk) 02:46, 20 November 2016 (CET)

Global Replacement Request

A spot to capture global replacement requests:

  • == Problems == > == <span title="Resolved problems are listed only for one prior release version.">Current Problems</span> ==: Aligning with wiki policies that purge older resolved problem reports. Kolano (talk) 01:37, 29 May 2015 (CEST)
  • Update testing/entry template to always include "tester=" field. Kolano (talk) 01:36, 29 May 2015 (CEST)

Game .ini Documentation?

This is kind of building off of the discussion had on Talk:Metroid_Prime_(GC) a year ago about gameini and its relevance to the wiki, but since I'm not talking about Prime in particular and that discussion is so old I'm going to post this here.

Gameini definitely needs documentation. I think everyone agrees with that. To your average user, it probably seems like magic that he starts his game and Dolphin starts changing settings all on its own before the game even starts, and there's really no mention of it anywhere that I've seen. It just sort of exists, and even as an outsider I've seen tension surrounding it, just from my own limited glimpses into Dolphin's development. There's confusion for developers and end-users, and it all stems (primarily) from a lack of proper understanding of what the gameini settings even do and why they're there in the first place for each particular game.

I'm thinking we could kill two birds with one stone here. What we have with the wiki is a really accessible, easily understandable format that's perfect for documenting something like this. Any undertaking to try and make sense of gameini is going to take TONS of effort and I understand that completely, but if it's going to be done, I think the best option is to do it in a setting like what we have here with the wiki. Here's my idea:

Under configuration right now, we list non-default settings. This is good, and it does its job well enough, but why not expand configuration to include current defaults from the gameini right next to the non-default settings? In a separate section of course, so it wouldn't be confusing trying to figure out what settings you need to change for the game. I'm thinking we could have an expandable window that defaults as closed so that if you're doing a quick scan through the page you wont be bombarded with twenty settings that would be useless to the standard end-user. With this comes some major pros, and also some major cons, and I'll list the ones I've thought of.


  • Very easy to update, moreso than anything else on the wiki pages right now. Any user could use three clicks in the latest revision to get the gameini contents from the game's properties.
  • Helpful for developers. This would keep track of current default settings in a way that's visually appealing, right next to the game's title and picture AND right next to the non-default settings to show what needs to be changed in the ini, making it much simpler to find specific games and their current settings rather than going through a giant list of game IDs and trying to find the specific ID which is for his game, probably having to use an external website like gameTDB to look up the ID, AND making it easier to understand what settings need to be changed.
  • Helpful for users. With gameini settings being listed prominently, being on the game's wiki page, it'd start to familiarize users with what the gameini actually does, and why it has different settings, removing the voodoo magic stigma that plagues gameini settings right now.


  • This would take TONS of manhours to set up initially, creating a new template with all the potential gameini settings and applying it to each and every game's page. There's not much you can do about that, but this is a problem not so much with the implementation in the wiki so much as it is a problem with how complex and expansive gameini is, and a problem anyone trying to document this would run into, which will only get worse as time goes on.
  • Games have multiple IDs, and different IDs can have (or even need) different settings, or be missing gameini entirely. I'm thinking for this, in the expandable window we could list the different IDs for the game horizontally on the top, and then the settings vertically on the side, making it into a grid of sorts. I don't know how difficult this would be to implement though in the template, but I'm thinking it could be done with some planning. However a user might accidentally edit the wrong column if he doesn't check his ID first, and nobody would know that the settings are wrong until they looked themselves for that specific ID. We'd need to specifically mention that before editing the user should double check the ID and make sure he's making his edits to the correct version.
  • Without enough people actually updating this, it could lead to more confusion than it already does. However I don't think this is as big of a problem as it seems since once again, anyone can check their accuracy with three clicks.

Other than that, I don't know. Like I've said twice this would be a huuuge undertaking, and I'm not suggesting we do it, like, today, but I'm thinking that with the right planning and some forethought we could definitely make this work. This will need a lot of feedback though, and I get that this idea is crazy, bordering on insanity, which is why I spent a full day thinking about it before posting this. - Xerxes (talk) 04:21, 7 December 2014 (CET)

Actually, we don't just list non-default settings. I've been making sure problems are added with a "fixed by X setting. This setting is enabled in the gameini, but if you open the graphics configuration window the problem may appear." And the configuration area usually has all of the settings, defaults or no. I think that's a good way to handle this. It documents it, without being so nuts as to have a "gameini template". I agree that GameINI documentation is important, as kosta doesn't seem very inclined to share the magic of what does what, but I don't think we need a massive overhaul - most of the information is already on the wiki in some form, and it's actually explained here. And since any pulling of gameinis would be entirely one way, and there is ZERO documentation in the gameinis, I don't recommend any tie in to the gameini database. I think the most important thing is for us to just adopt the above scheme as the official convention. and let time and constant work fill in the blanks. - MaJoR (talk) 08:11, 7 December 2014 (CET)

I understand what you mean, but there seems to be a disconnect here really. The Configuration template specifically states "non-default settings" and I've done cleanup of preset gameini settings before. I could go back and revert all those edits but right now the gameini information on the wiki is inconsistent at best and nonexistent the majority of the time, there's mentions of it here or there like on the Prime page but it's very loosely organized and generally not easy to understand at a glance (like the .ini files themselves). On the one hand, keeping every setting a game needs in Configuration is the best idea just in general for keeping track of the general state of different games' compatibility, but on the other hand it's confusing and may make new users do extra unnecessary work in Dolphin's config to get their games to run when those settings get overridden by the ini anyways. The template would allow for these settings to be clearly defined, separate from the non-default configuration, without interfering with the rest of the page's contents or cluttering Configuration/Problems with settings most users won't need to change or even know needed to be changed in the first place. We don't need to start off by adding it to every page on the wiki, maybe add it here or there as a sort of trial run for mainstream games with well documented required settings currently set by the ini, and if it doesn't pan out we can ditch it.

Or we could start labelling settings inside of the current Configuration template if they're preset by the gameini or not, though this would contradict with the global explanation for Configuration on every page of the wiki. Maybe it could be done as simply as adding a checkmark/X column to the configuration on the left side, checkmark for preset, X for not preset, or something to that effect. In the end it doesn't matter what way it's decided to do this but I think there should be some common agreement (I don't want to say policy, but maybe) on how exactly to go about explaining that settings are needed but set by default, because there doesn't really seem to be any common ground from one game's page to another when it comes to this. - Xerxes (talk) 08:56, 7 December 2014 (CET)

Remember what the wiki conventions say?

"These are all "common law" concepts; no one has ever set in stone how these things work, they are simply what has grown out of the wiki over its many years of existence. And they will continue to evolve as the wiki grows, and this page will be updated periodically to reflect the changes that have occurred. These conventions are not "rules" in any sense of the word, but guidelines, instructions, and help for those new to the wiki."

The non-default standard was created before the gameini system. It was created because the wiki had tons of "use EFB to Texture for speed!" things, or people just listing every setting in their emulator on a game page because it worked for them. ICK. The rules are fluid and change as circumstances change. And the circumstances have changed since that concept was enacted. The wiki needs to change with it. And that's where the non-standardization has come from - when something is not working with the current standard, things get messier and weird. The current standard isn't working, and so other ideas come in to fit the moment, and it gets mushy. It's one of the first signs that we need to start doing some tweaks. And don't worry about global explanations in the templates, all it takes to change them is consensus.

Regarding the config area, I don't think leaving things that the gameinis override is really an issue. Most users only come to the wiki when an problem occurs, and want answers as to why that problem exists. If the user is opening the graphics configuration out of habit and needs the wiki to get them to set it in the GUI to stop the habit, I'm all for it. Still, some changes to the config template might be good. some way to show gameini and non-gameini settings would be good. Unfortunately that is difficult to track and maintain, however. Kosta just does what he does and that's it. Unfortunately, the only simple solution is to just list everything the game needs, gameini or no, which is essentially what many pages already have. I have no problem with that though, but I would prefer a more elegant solution. As for problems, just list the problem out, and then say "setting set by default in the game ini but can occur under X" seems fine to me. The problems area is the best way to document bugs that the gameini overrides, since it gives us plenty of room to explain it.

Btw, any change to the templates needs to be global. That's just how the dolphin wiki is. But we can set up test pages and test templates to work out kinks.

Oh, and I would appreciate it if you reverted those cleanups. You jumped the gun a little bit there to talk about this issue after killing a bunch of stuff.

- MaJoR (talk) 12:11, 7 December 2014 (CET)|

Fine with me. I have no problem at all reverting the edits, it'll just clutter the recent changes page a bit. One of the reasons I started this topic was because I was starting to find a lot of config stuff that was preset in the ini and I stopped purging them to get some feedback on a better way to do this, and suggest an idea (which I admit isn't perfect in the slightest). I'll try and add notes whenever possible to the Problems section explaining each issue following that format, but it'll probably take me a full day or two just to do all that writing.

I still think there's potential in a new config template or at least some kind of formalization of how this is done, whether it's through the Problems section or its own unique section, but like I said I'm not really in favor for any one plan and I was mostly throwing ideas at the wall to see what sticks. Personally the way I've used the wiki for years is to check a new game I'm going to run in Dolphin and see what the general consensus is and what settings it needs or doesn't need before I play, I've never really been reactionary so I didn't consider that viewpoint at all. I still think this is a particularly important place that the wiki could be improved though but for right now if leaving settings in gameini and making note of them in Problems is the way it's being done, that's how I'll do it until there's some better infrastructure in place for this.

That was easier than expected. Most of my changes to configuration were outdated LLE requirements, so I only had a few pages to revert. But I'll keep to this format in the future if you think the pages I changed back look OK. - Xerxes (talk) 13:55, 7 December 2014 (CET)

This is ongoing at GameINI Settings/Sandbox and needs to be brought to completion. Kolano (talk) 08:25, 6 October 2015 (CEST)

Oh yea, I never did finish that... In part because Link to the past will probably never touch it. Maybe if it's an official guide (on the main page) we can tempt him to? Hmm... It might be worth sending him a PM and asking. - MaJoR (talk) 12:34, 7 October 2015 (CEST)

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, 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 - Jhonn (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 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. - MaJoR (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, 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)

Wii Network compatibility

Now that the wii-network was merged to master and we also have a stable release that support, it would be nice having a compatibility chart or rating somewhere. From tests I ran with the games that I own that have Nintendo WFC features, I suggest something like that:

  • Broken: none of the WFC features work
  • Unsupported: titles servers down (like MH3)
  • Good: titles that have an online mode that works but some features (like Friend Codes or DLC) doesn't work or have other issues
  • Perfect: titles that works in Dolphin with all WFC features it has

I'm not sure where we could put this, but my only suggestion for now is having a entry in the Infobox of games that have WFC capabilities. For functionalities that may need a NAND dump (like getting DLC) we could "rate" as good and then put a small note or tooltip. What about that? Jhonn (talk)

I'm not really a fan of this idea. It's a lot of information to deal with and will be very hard to maintain. Most users won't bother with it. Will you maintain it? - MaJoR (talk) 04:37, 14 October 2013 (CEST)
I was also hoping to capture some further detail of titles with online features. Though many titles are covered by the "Online" modes indicator, that only covers titles supporting multiplayer online play. Some additional infobox field to show network characteristics is probably a good idea. I'd agree with major though, that we should be careful regarding the level of detail we go into. Kolano (talk) 06:05, 14 October 2013 (CEST)
What about something like the ratings template? You put a number in a template subpage with the name of the game and then in the infobox we display a small text (rather than stars). I'm willing to maintain games that I own (if we proceed implementing this), but if only one person is going to handle this then the amount of work needed to implement the functionality doesn't compensate. Any other idea to simplify this to an easier way of managing? Jhonn (talk)
The rating list you have above may be OK, though we need to differentiate between what you've listed as "Unsupported" above, and games that actually don't support online features at all, I'd lean towards a -1 "Servers offline" rating, 0 for unsupported, and 1-3 for supported titles. We likely should also include a notes field to provide details of issues for the Broken/Good categories (it would also be good to disallow "Perfect" ratings if issues were noted. (I also revised the text above to use "title" rather than "game", we need to remember that not all Wii software titles are games).
One other thing we may need to account for are tiles who's original servers are offline, but replacement servers are provided for. Though, unlike the many PC titles replacement servers have been provided for, GameCube/Wii titles may be too undocumented to provide separate server support for, it may be something the Dolphin team will want to support in future.Kolano (talk) 04:52, 15 October 2013 (CEST)

Error with Slash in Search

Using a forward slash in a search term (i.e. "NA/EU") results in a 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)