Project:General Discussions: Difference between revisions

From Dolphin Emulator Wiki
Jump to navigation Jump to search
(46 intermediate revisions by 6 users not shown)
Line 2: Line 2:


== Open Discussions ==
== Open Discussions ==
=== Problems section automation ===
=== Global Replacement Request ===
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 {{tl|issue}} or {{tl|s}} being called somewhere in the page, which isn't always the case.
A spot to capture global replacement requests:
 
* Update testing/entry template to always include "tester=" field. [[User:Kolano|Kolano]] ([[User talk:Kolano|talk]]) 01:36, 29 May 2015 (CEST)
After some tinkering, I think I found a good way to address those points without making things complicated. It's actually using the new {{tl|Problems}} template I just made. Similar to {{tl|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):
 
<pre>
== 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}}.
</pre>


To use {{tl|Problems}}, the modification in the page is pretty small. For example, that's how it would look:
=== Titles without GameINI entries vs Rating ===
<pre>
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]]. - [[User:mbc07|mbc07]] ([[User talk:mbc07|talk]]) 01:56, 13 March 2017 (CET)
== Problems ==
{{Problems|


=== Problem 1 ===
: 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.
Game XXX has an issue when using save states, which will corrupt your save file.
: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.
:[[User:Kolano|Kolano]] ([[User talk:Kolano|talk]]) 06:08, 13 March 2017 (CET)


{{Problems/VP6 Videos}}
:: 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 [[User:MayImilae|MayImilae]], the 3-star rating from myself or that "blue stars" thing from [[User:Lucario|Lucario]]) - [[User:mbc07|mbc07]] ([[User talk: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. [[User:Lucario|Lucario]] ([[User talk:Lucario|talk]]) 00:16, 18 March 2017 (CET)
::::5% of the population has some form of color blindness... - [[User:MayImilae|MayImilae]] ([[User talk: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. [[User:Lucario|Lucario]] ([[User talk:Lucario|talk]]) 07:20, 24 March 2017 (CET)


=== <s>Fixed Problem 2</s> ===
:: Side note, since it seems you've been doing some Channel testing. Can you fill in the missing Channel GameIDs, mbc07?
Game XXX will display corrupted graphics when using EFB2Tex, use EFB2RAM to avoid that. Fixed in {{revision|5.0-1000}}.
::: 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? - [[User:mbc07|mbc07]] ([[User talk: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. [[User:Kolano|Kolano]] ([[User talk:Kolano|talk]]) 21:02, 17 March 2017 (CET)
</pre>


The call to {{tl|Problems}} should be added into every game page (and well, we have MassEditRegex in our favour) and it has the following advantages:
: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. - [[User:MayImilae|MayImilae]] ([[User talk:MayImilae|talk]]) 03:48, 24 March 2017 (CET)
* It deprecates {{tl|s}} and {{tl|/s}} and also the workaround currently implemented in {{tl|issue}} templates. It also somewhat achieves the same goals of the experimental {{tl|Active}} and {{tl|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 {{tl|Problems}} subtemplates as well.
* You can also use the <tt>type=</tt> parameter to better reflect the page type (e.g. channel pages). This parameter is optional and works exactly like the <tt>type=</tt> parameter from {{tl|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]]). - [[User:Jhonn|Jhonn]] ([[User talk: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. [[User:Kolano|Kolano]] ([[User talk: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...
:*[[Harry Potter and the Prisoner of Azkaban]] ([https://wiki.dolphin-emu.org/index.php?title=Harry_Potter_and_the_Prisoner_of_Azkaban&oldid=126383 /wo template]
:*[[The Price Is Right 2010 Edition]] ([https://wiki.dolphin-emu.org/index.php?title=The_Price_Is_Right_2010_Edition&oldid=124728 /wo template]
:...Price is Right shows it successfully adding to [[:Category:Pages with active problems]] category without an embedded {{tl|Issue}}. Would be nice if some extra parsing could allow flagging such (i.e. problems /wo issues).
:[[User:Kolano|Kolano]] ([[User talk: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. [[User:Kolano|Kolano]] ([[User talk: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, <s>I think it's doable by using #varfinal, I'll try to get that working</s> 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 - [[User:Jhonn|Jhonn]] ([[User talk: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". [[User:Lucario|Lucario]] ([[User talk: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. [[User:Lucario|Lucario]] ([[User talk: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 <nowiki><s></s></nowiki>) and after that it loops through the text of each "active" heading it found earlier querying for "<nowiki>[https://dolp.in/i<number>]</nowiki>" (it wasn't possible to search for {{tl|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 {{tl|s}}, {{tl|/s}}, {{tl|active}} and {{tl|fixed}} or the workaround in {{tl|issue}}. If there's nothing more you guys want to ask or to add on {{tl|Problems}}, I'll start implementing it on all pages... - [[User:Jhonn|Jhonn]] ([[User talk: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? [[User:Lucario|Lucario]] ([[User talk: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. [[User:Kolano|Kolano]] ([[User talk: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 {{tl|Problems}} behavior on different scenarios when used on VC pages. Is there anything else you guys want? - [[User:Jhonn|Jhonn]] ([[User talk: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. [[User:Lucario|Lucario]] ([[User talk: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) - [[User:Jhonn|Jhonn]] ([[User talk: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". [[User:Lucario|Lucario]] ([[User talk:Lucario|talk]]) 22:52, 25 November 2016 (CET)


=== Problems / Global Problems Merging ===
=== 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? [[User:Lucario|Lucario]] ([[User talk:Lucario|talk]]) 21:03, 24 November 2016 (CET)
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? [[User:Lucario|Lucario]] ([[User talk: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. - [[User:Jhonn|Jhonn]] ([[User talk:Jhonn|talk]]) 00:44, 25 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. - [[User:mbc07|mbc07]] ([[User talk:mbc07|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]]. [[User:Lucario|Lucario]] ([[User talk:Lucario|talk]]) 22:52, 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]]. [[User:Lucario|Lucario]] ([[User talk: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 {{tl|Problems}} BTW) it can be ported directly to {{tl|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). - [[User:Jhonn|Jhonn]] ([[User talk:Jhonn|talk]]) 02:59, 26 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 {{tl|Problems}} BTW) it can be ported directly to {{tl|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). - [[User:mbc07|mbc07]] ([[User talk: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. [[User:Lucario|Lucario]] ([[User talk:Lucario|talk]]) 22:37, 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. [[User:Lucario|Lucario]] ([[User talk:Lucario|talk]]) 22:37, 26 November 2016 (CET)
Line 83: Line 42:


:::::: 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).  
:::::: 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 {{tl|Problems}} on the pages sometime during this week. - [[User:Jhonn|Jhonn]] ([[User talk:Jhonn|talk]]) 06:52, 27 November 2016 (CET)
:::::: 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 {{tl|Problems}} on the pages sometime during this week. - [[User:mbc07|mbc07]] ([[User talk: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?
::::::: 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?
Line 96: Line 55:
::::::::: * '''[[: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.
::::::::: * '''[[: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 {{tl|GlobalProblems}} or its variables inside {{tl|Problems}}, that's actually another reason to keep the sections separated: {{tl|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. - [[User:Jhonn|Jhonn]] ([[User talk:Jhonn|talk]]) 03:06, 29 November 2016 (CET)
::::::::: 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 {{tl|GlobalProblems}} or its variables inside {{tl|Problems}}, that's actually another reason to keep the sections separated: {{tl|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. - [[User:mbc07|mbc07]] ([[User talk:mbc07|talk]]) 03:06, 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 [https://en.wikipedia.org/wiki/Wikipedia:Category_intersection#Tools_currently_available this mediawiki page] then you will find the various options for doing so. however, dolphin wiki's [https://wiki.dolphin-emu.org/index.php?title=Special:Search 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 [https://www.mediawiki.org/wiki/Extension:Multi-Category_Search 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.
 
[[User:Drmario|Drmario]] ([[User talk: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 [https://www.mediawiki.org/wiki/Extension:DynamicPageList3 DPL3 extension] we have on this wiki to generate a report of pages which intersect as workaround. [[User:Kolano|Kolano]] probably can help you more with its usage (you can also check any of the [[Template:Problems|Problems]] templates for usage examples as they also uses DPL3 extension). - [[User:Jhonn|Jhonn]] ([[User talk: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 [http://help.gamepedia.com/DPL:Example_-_Select_by_Category 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 [https://www.mediawiki.org/wiki/Extension:Multi-Category_Search 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.
:::::::::: 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...
:: [[User:Drmario|Drmario]] ([[User talk:Drmario|talk]]) 14:30, 17 September 2016 (CEST)


== Recent Discussions ==
:::::::::: I'm fine with Problem template going official now. [[User:Lucario|Lucario]] ([[User talk:Lucario|talk]]) 23:16, 29 November 2016 (CET)
Below is listed of recently concluded discussions. You can [[Project:General_Discussions/Archive|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?
** <s>Updates to the {{tl|Revision}} and {{tl|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.</s> (done, I think)
** <s>Purging of [[:Category:Pages_with_fixed_problems|4.0 resolved issues]]</s> (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! - [[User:MaJoR|MaJoR]] ([[User talk: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! - [[User:MaJoR|MaJoR]] ([[User talk:MaJoR|talk]]) 22:10, 14 June 2016 (CEST)
 
:So, what's the plan? Wait until 5.0 is out officially to start purging <s>crossed</s> entries? Or start right now? I have some free time during this week, so I can help with the purging... - [[User:Jhonn|Jhonn]] ([[User talk:Jhonn|talk]]) 05:05, 15 June 2016 (CEST)
::Weren't we going to automate it? - [[User:MaJoR|MaJoR]] ([[User talk: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... - [[User:Jhonn|Jhonn]] ([[User talk: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 - [[User:MaJoR|MaJoR]] ([[User talk: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. [[User:Kolano|Kolano]] ([[User talk: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. - [[User:MaJoR|MaJoR]] ([[User talk: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? - [[User:Jhonn|Jhonn]] ([[User talk: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 >_< - [[User:MaJoR|MaJoR]] ([[User talk: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 <s>crossed</s> entries isn't that big) - [[User:Jhonn|Jhonn]] ([[User talk: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. [[User:Lucario|Lucario]] ([[User talk: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... - [[User:Jhonn|Jhonn]] ([[User talk: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 [[Special:MassEditRegex|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. - [[User:Jhonn|Jhonn]] ([[User talk: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 :) - [[User:Jhonn|Jhonn]] ([[User talk: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. [[User:Kolano|Kolano]] ([[User talk:Kolano|talk]]) 05:32, 20 June 2016 (CEST)
 
::: The logging is there, but just like the other bots, it's [https://wiki.dolphin-emu.org/index.php?title=Special:RecentChanges&hidebots=0 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:
::: '''Find:'''
::: <tt>/(?:\={3}\s\{{2}s\}{2}[\s\S]*?\{{2}\/s\}{2}\s\={3})([\s\S]*?(?=\s\=))/</tt>
::: <tt>/(\n{3,})(\n=)/</tt>
 
:::'''Replace:'''
::: <tt><empty line - placeholder to avoid it being crushed by formatting> </tt>
::: <tt>\n$2</tt>
 
:::: 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. [[User:Kolano|Kolano]] ([[User talk:Kolano|talk]]) 00:39, 28 June 2016 (CEST)
 
:::... which essentially matched every entry in the format <tt>=== <nowiki>{{s}}whatever{{/s}}</nowiki> ===</tt> and then fixed the excess of line breaks left by the first expression. - [[User:Jhonn|Jhonn]] ([[User talk: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. [[User:Kolano|Kolano]] ([[User talk: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) - [[User:Jhonn|Jhonn]] ([[User talk: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. [[User:Kolano|Kolano]] ([[User talk: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 {{tl|Revision}} and {{tl|VersionRevision}} templates and the notice message at the top of our wiki and we're done! YAY! - [[User:Jhonn|Jhonn]] ([[User talk: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]]? [[User:Kolano|Kolano]] ([[User talk:Kolano|talk]]) 02:46, 20 November 2016 (CET)
 
=== Global Replacement Request ===
A spot to capture global replacement requests:
* == Problems == > == &lt;span title="Resolved problems are listed only for one prior release version."&gt;Current Problems&lt;/span&gt; ==: Aligning with wiki policies that purge older resolved problem reports. [[User:Kolano|Kolano]] ([[User talk:Kolano|talk]]) 01:37, 29 May 2015 (CEST)
* Update testing/entry template to always include "tester=" field. [[User:Kolano|Kolano]] ([[User talk: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.
 
Pros:
 
*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.
 
Cons:
 
*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. - [[User:Xerxes|Xerxes]] ([[User talk: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. - [[User:MaJoR|MaJoR]] ([[User talk: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. - [[User:Xerxes|Xerxes]] ([[User talk: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.
 
- [[User:MaJoR|MaJoR]] ([[User talk: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. - [[User:Xerxes|Xerxes]] ([[User talk:Xerxes|talk]]) 13:55, 7 December 2014 (CET)
 
This is ongoing at [[GameINI Settings/Sandbox]] and needs to be brought to completion. [[User:Kolano|Kolano]] ([[User talk: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. - [[User:MaJoR|MaJoR]] ([[User talk:MaJoR|talk]]) 12:34, 7 October 2015 (CEST)


=== MD5 / GameID capture ===
=== MD5 / GameID capture ===
Line 246: Line 68:
Adding this section for future discussion so we can hopefully eventually move forward with such. [[User:Kolano|Kolano]] ([[User talk:Kolano|talk]]) 07:58, 29 September 2014 (CEST)
Adding this section for future discussion so we can hopefully eventually move forward with such. [[User:Kolano|Kolano]] ([[User talk: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 - [[User:Jhonn|Jhonn]] ([[User talk:Jhonn|talk]])
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 - [[User:mbc07|mbc07]] ([[User talk: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). [[User:Kolano|Kolano]] ([[User talk:Kolano|talk]]) 00:22, 30 September 2014 (CEST)
: 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). [[User:Kolano|Kolano]] ([[User talk: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. - [[User:MaJoR|MaJoR]] ([[User talk:MaJoR|talk]]) 08:05, 2 October 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. - [[User:MayImilae|MayImilae]] ([[User talk: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? [[User:Zephyrsurfer|Zephyrsurfer]] ([[User talk:Zephyrsurfer|talk]]) 10:18, 12 November 2014 (CET)
:If this gets implemented, which I'm for, could we record if it's a SL or DL disc as well? [[User:Zephyrsurfer|Zephyrsurfer]] ([[User talk:Zephyrsurfer|talk]]) 10:18, 12 November 2014 (CET)
Line 262: Line 84:
:::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. --[[User:Wildgoosespeeder|Wildgoosespeeder]] ([[User talk:Wildgoosespeeder|talk]]) 04:45, 10 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. --[[User:Wildgoosespeeder|Wildgoosespeeder]] ([[User talk:Wildgoosespeeder|talk]]) 04:45, 10 May 2015 (CEST)


=== 3D Support ===
=== Error with Slash in Search ===
Now that Dolphin has proper 3D support, we need to figure out a way to deal with 3D related problems. Me and JMC47 have been talking about what to do for a while, and uh, well, I kind of forgot to brought it up here. So here we are. Since we are not just limited to 3D vision, yet most of our testing (what little there is) will be on 3D vision, it's a lot of limitations already. My main issue with 3D support as a whole is that we are going to have very few reports on this, just on the popular games, so putting it in it's own section on each game or just in the problems area seems weird to me. That, and if a 3D vision error comes up (see the recent edit in NSMBW), is it 3D vision, or an underlying issue that would affect all 3D? And since it only affects an enhancement that very few users can even use, does it belong in the problems area at all?
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"
[[User:Kolano|Kolano]] ([[User talk:Kolano|talk]]) 22:01, 28 August 2013 (CEST)


Here is my proposal - a dedicated page for 3D Support. The page would have instructions for set up (all platforms), as well as a listing of game test results and any texture hacking/cheating required and problems encountered. While I kind of wish we had a method for letting the test results just go into the source game and then collect all testing entries with a 3D field in them into this single page but uh, I don't know how to do that. Regardless, the point of having it all together is that people will actually be able to FIND it, and we don't have to worry about random outdated 3D stuff being spread all over the place. Win win.
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. [[User:Kolano|Kolano]] ([[User talk:Kolano|talk]]) 07:04, 13 March 2017 (CET)


What do you guys think? - [[User:MaJoR|MaJoR]] ([[User talk:MaJoR|talk]]) 08:20, 3 August 2014 (CEST)
== Recent Discussions ==
 
Below is listed of recently concluded discussions. You can [[Project:General_Discussions/Archive|search the archive]] for what was discussed since General Discussions page was created.
: I liked the concept, but I'm unsure on how to grab the testing entries... Not sure if there's a way to share testing entries between pages without needing major rewrites in testing template code. - [[User:Jhonn|Jhonn]] ([[User talk:Jhonn|talk]])
 
: I'd presume Major's intent was that only 3d related test results would appear there, so the need to share results between pages would be minimized. Honestly the appropriate way of handling this would be to implement something like the current rating templates to allow things to be shared between pages, but I have the feeling no one is really willing to deal with the setup/maintenance cost related to such. At the moment, as Major indicates, I think we may be best off with a separate page devoted to 3d, with a separate listing of games only when they had specific 3d problems. Please correct me if I'm wrong here, but I would guess most issues would be purely game related and would still appear on the game pages. Some issues, related to the games not providing appropriate 3d information, due to them presuming they are displayed on a 2d device, would appear on the 3d description/issues page.
 
: I guess my opinion here is that, if we had some buy-in enabling the sorts of mass edits needed to create/embed 3d config/issues templates across pages I'd prefer that, but outside of that a centralized page is an OK way of handling it otherwise. (p.s. looking through the rest of the discussion here we have some cleanup to do.) [[User:Kolano|Kolano]] ([[User talk:Kolano|talk]]) 08:16, 5 August 2014 (CEST)
 
::Yea that's pretty much the idea. Having it all in one place. The idea of having test entries and pulling them here too was just a side idea. The main thing is to have them in ONE PLACE. I'll set up a page and start experimenting with it. JMC47 has collected a ton of information and I'll be working with him on it. If you guys have a better idea than what I'm doing as I'm doing it please jump onto the talk page and point it out. I'm kind of winging it. - [[User:MaJoR|MaJoR]] ([[User talk:MaJoR|talk]]) 09:59, 7 August 2014 (CEST)
 
This is still being implemented at [[Stereoscopic_3D_Support_and_Compatibility/Sandbox]]. Someone needs to clean such and get it out of the sandbox.[[User:Kolano|Kolano]] ([[User talk:Kolano|talk]]) 08:24, 6 October 2015 (CEST)
 
=== Perfect Compatibility? ===
I'd like you to take a look at the SSB:M compatibility page. This game is rated 5 stars as "Perfect: No issues at all!". Yet, there seems to be one or two minor, ''minor'' errors listed on the page.
 
So what is the specific criteria for a perfect rating? Would no known bugs, period, be too out of the question? Or is "perfect" emulation accuracy unreasonable anyhow, considering it isn't cycle for cycle accurate and won't be anytime soon. Basically, can we define the word perfect?
 
[[User:MirandaStreeter|Miranda]] ([[User talk:MirandaStreeter|talk]]) 01:16, 24 October 2013 (CEST)
 
Perfect should mean there are no known issues/defects with the reproduction. It's unclear why Melee wasn't knocked back to 4 stars earlier, since it clearly has open issues. As you note it doesn't necessarily mean there is an exact 1:1 reproduction, as we're dealing with high-level emulation in many places. There should not be noticeable image defects/gameplay issues though. So for instance, even if a character starts to talk a tenth of second too late in some title; it could still be rated perfect, if that doesn't effect gameplay and would generally be unnoticeable without a stopwatch. [[User:Kolano|Kolano]] ([[User talk:Kolano|talk]]) 04:13, 24 October 2013 (CEST)
:SSBM isn't the only offender. A number of games seem to be 5-star happy yet have known issues listed without fixes. These include:
::* Aggressive Inline
::* Harvest Moon: Magical Melody
::* Ikaruga
::* Sonic Adventure DX: Director's Cut
::* Tales of Symphonia
:Yet more are listed at 5 stars without any version compatibility reports or test. None at all. These include:
::* Donkey Konga
::* Dora the Explorer: Journey to the Purple Planet
::* Hitman 2: Silent Assassin
::* Hudson Selection Vol. 3: Bonk's Adventure
::* Mr Driller: Drill Land
::* Pac-Man World Rally
:You'll also find some 5-star games that require DX9 backends as a fix, despite it being entirely dropped in latest revisions. These include:
::* Hot Wheels World Race
::* Sega Soccer Slam
:While all of those are obvious fixes, others aren't so much. Many of the rest either have conflicts between the reporting graph and actual report entries, list 4 stars in the graph while reading 5 stars in the official list, are listing compatibility results without any details, or haven't had a test entry since v3.0 and previous. These would have to be looked into on a case by case basis. I'd also check and see if a specific user/IP is marking 5 stars prematurely, or if it's a collective problem. --[[User:MirandaStreeter|Miranda]] ([[User talk:MirandaStreeter|talk]]) 21:10, 30 October 2013 (CET)
-----
Whoa now. This is exactly the problem. ALL GAMES HAVE SOMETHING WRONG WITH THEM. A tiny lighting bug. Tev derp. SOMETHING. By the criteria of "no known problems" there should be no five star titles. And even if we keep the ones that have no known bugs, it is just a matter of time until someone grabs one of those tiny global problems and there we go. The "perfect" rating concept is inherently flawed.
 
As was discussed in the rating changes below, it is the opinion of the devs (minus skidau) that 5 stars ''should not mean absolute perfection''. 5 stars is something we should use, and since the emulator isn't perfect then nothing would be five stars. The criteria that was discussed is below in the Rating Changes section. That criteria is "almost perfect". Very very very good, with allowances for very minor bugs. Melee is a perfect example. Everything is perfect, except for some very very tiny bugs that no one bug someone who goes back and forth from console and dolphin a lot would notice (JMC47 and the netplay people in this case). Under the "almost perfect" criteria Melee is five stars.
 
We need to work this out. We've been putting off this rating thing forever, and now that demotions are starting to happen based on the old ratings, it's time to get this settled. Until this rating issue is settled please do not demote any more 5 star games. Kolano, if you revert 5 star pages I won't get into an edit war with you, you pretty much handle all the boring tasks like this and I respect that. But anyone else? I'm reverting all five star demotions until the ratings issue is settled permanently.
 
For the record, I promoted Melee to five stars based on encouragement from the devs that it qualified for "perfect" status regardless of the little bugs (again, skidau objecting :P). - [[User:MaJoR|MaJoR]] ([[User talk:MaJoR|talk]]) 22:27, 30 October 2013 (CET)
 
=== Ratings Changes ===
As you know, our ratings are old. Very old. I'll paste them here for memory sake.
 
::[[File:Stars0.png]] Unknown: Has not been tested yet
::[[File:Stars1.png]] Broken: Crashes when booting
::[[File:Stars2.png]] Intro/Menu: Hangs/crashes somewhere between booting and starting
::[[File:Stars3.png]] Starts: Starts, maybe even plays well, but crashes or major graphical/audio glitches
::[[File:Stars4.png]] Playable: Runs well, only minor graphical or audio glitches. Games can be played all the way through
::[[File:Stars5.png]] Perfect: No issues at all!
 
Because of how vague that is and the need to handle more complex situations, we (or at least I) generally operated on a variant of those. Here they are.
 
::[[File:Stars0.png]] Unknown: Has not been tested yet
::[[File:Stars1.png]] Crashes when booting
::[[File:Stars2.png]] Cannot reach gameplay but can reach menus
::[[File:Stars3.png]] Major unsolvable issues
::[[File:Stars4.png]] Minor unsolvable issues or fixable major issues
::[[File:Stars5.png]] Perfect (with some tolerance for issues too minor to be user noticeable)
 
 
Now this has been the case for a long, looooong time. But there are a lot of problems with this. There are almost no 1 and 2 star pages anymore. Dolphin has evolved past the point where such a system is needed. Furthermore, the scope of each rating is vast: a game that has major graphics glitches but is completely playable: 3 stars. A game that has severe stuttering and is utterly unplayable: 3 stars. A game that crashes during the first level: 3 stars. Plus, 4 and 5 star ratings are vague and weird.
 
So, to solve this, we discussed it in the IRC and we hammered out a proposal that should address these issues. Most of them anyway. Here it is:
 
::[[File:Stars0.png]] Untested
::[[File:Stars1.png]] Does not pass the main menus
::[[File:Stars2.png]] Unplayable or cannot be completed
::[[File:Stars3.png]] Main mode can be completed, but has major glitches/crashes or missing modes
::[[File:Stars4.png]] Minor issues
::[[File:Stars5.png]] Perfect with the right settings


Now, obviously it's a little vague here and there. That can't be fixed; what determines minor bugs, major bugs, unplayable is a bit subjective. And there are some decisions that have to be made:  
=== 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. [https://github.com/dolphin-emu/dolphin/blob/master/Data/Sys/GameSettings/0000000100000002r1.ini 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. - [[User:PowerKitten|PowerKitten]] ([[User talk:PowerKitten|talk]]) 19:09, 9 October 2017 (CEST)


*is it Perfect if a super tiny non-user noticeable bug remains? Example - {{issue|6398}}.
: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 {{PR|5763}}, 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?
*if it requires an extreme compatibility setting (interpreter, LLE, EFB to Ram uncached, MMU) with a significant performance hit to be perfect, should it still be marked as perfect? And if so what settings count for that?
*Is user configuration a component of this rating? If a major bug can be fixed is it still 3 stars or is it put up to 4 or 5?


And of course it could use a little polishing in phrasing and the like. Still, I think overall this is a lot better. Removing "crashes on boot" gives us more room in 3-4-5 to make the ratings more specific. Plus, most of the changes are in the 1-2 star range, so it won't require us change ratings for every single game on the entire wiki. That's definitely a benefit.
: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). - [[User:Xerxes|Xerxes]] ([[User talk:Xerxes|talk]]) 20:27, 9 October 2017 (CEST)


So guys, what do you think? We'll need to get as many specifics as we can hammered out before we go along with this. If things get too complicated we can use [[Project:Wiki Conventions]] for detailed information and have a trimmed down version in the ratings guide. It's work, definitely, but this is a long standing crappy system that really could use an overhaul. When it's done, this should be a nice improvement for us. - [[User:MaJoR|MaJoR]] ([[User talk:MaJoR|talk]]) 06:11, 23 August 2013 (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. - [[User:PowerKitten|PowerKitten]] ([[User talk:PowerKitten|talk]]) 16:13, 10 October 2017 (CEST)


: Well, I'm in with it. About rating 4 and 5, I think that if a game need an extreme setting (interpreter, LLE, EFB to Ram uncached, MMU), we should mark it as 4. Otherwise, mark it as 5. And for graphical related issues, if the problem is backend specific and the issue can be fixed by using OpenGL (that works Windows/Mac/Linux), we should mark as 5, otherwise mark it as 4. Despite this two notes, I agree with the rest - [[User:Jhonn|Jhonn]] ([[User talk:Jhonn|talk]])
=== Gameplay Screenshots section worth staying? ===
:: I agree with Jhonn on this. I'd even go further and say games that require interpreter, video software or full MMU+TLB emulation (=> no way to run even at 50% speed on any current computer) should be marked as 2 (unplayable) instead of 4. LLE, EFB to Ram uncached should be 4. Not sure about Single Core / SyncGPU. Please tell me when you reach a decision, I'll need to update the website to match that. [[User:Delroth|delroth]] ([[User talk:Delroth|talk]]) 14:14, 25 August 2013 (CEST)
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? [[User:Lucario|Lucario]] ([[User talk:Lucario|talk]]) 23:59, 25 February 2017 (CET)
:I'm fine with screenshots leaving! The wiki was never good at handling them. - [[User:MayImilae|MayImilae]] ([[User talk:MayImilae|talk]]) 04:10, 26 February 2017 (CET)
::Yeah, Wiki doesn't seem a good place for users' gameplay screenshots. [[User:Lucario|Lucario]] ([[User talk:Lucario|talk]]) 23:26, 1 March 2017 (CET)
:Agreed that they haven't gotten enough attention to be worth preserving. [[User:Kolano|Kolano]] ([[User talk: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 {{tl|Image}} a bit... - [[User:mbc07|mbc07]] ([[User talk: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. [[User:Lucario|Lucario]] ([[User talk: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. [[User:Kolano|Kolano]] ([[User talk: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 {{tl|image}} too, it has a special case coded for handling Gameplay Screenshots section... - [[User:mbc07|mbc07]] ([[User talk:mbc07|talk]]) 02:39, 2 March 2017 (CET)


: I'm generally OK with rehashing the definitions, but it will be a big job to re-align existing rankings. It looks like anything that was a 1 or 2 becomes a 1, which we could automate and 5 would stay 5 but all the 3/4 rankings would likely need investigation. We'll need some way to flag ratings that have been checked, perhaps we can script adding a comment/category into ratings pages to indicate ratings need review.
: 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. - [[User:mbc07|mbc07]] ([[User talk:mbc07|talk]]) 07:49, 4 March 2017 (CET)
:I'm a bit concerned regarding the "Perfect with the right settings" description for 5 stars though. I'd prefer to keep that as "Perfect with default settings", since if special settings are needed we likely should be looking at updating game ini's to provide more appropriate defaults. Such aligns with current page handling as well since: Config entries should generally have related Problem entries explaining why a setting is needed, and games with problems aren't perfect.
:On the topic of ratings, it might be nice if the ratings link took you to a list of titles with that rating rather than just to the rating definitions. Adding a set of categories should handle that easily enough. [[User:Kolano|Kolano]] ([[User talk:Kolano|talk]]) 21:52, 27 August 2013 (CEST)<br/>
<br/>
In adding my two cents, I'd like to adress something I thought I read here, but apparently didn't (seeing as I can't find it now) where someone was against using the word "perfect"; I too am against using that word, partially on philosophical/semantic grounds, but also in a more practical sense; since most of Dolphin is HLE (as opposed to full LLE (admittedly rare, but there are projects, e.g. the "higan" emulator, who attempts to do this)), using the word "perfect" here seems out-of-place. I instead propose the use of the word "Excellent", as in "Works excellently". Another option is "Flawless", as in that it works without flaws.<br/>
On the actual ratings though, I find that "Level 3" (i.e. [[File:Stars3.png]]) for both the old (i.e. "Starts: Starts, maybe even plays well, but crashes or major graphical/audio glitches") and the IRC-born suggestion (i.e. "Main mode can be completed, but has major glitches/crashes or missing modes") are slightly misleading, and the example I use for this is [[Mario Power Tennis (GC)]] which with both definitions would probably be a 3. However, this isn't really the case for the end-user, as the "graphical glitches" in Mario Tennis makes it completely unplayable. If you're lucky, you can view enough of the screen to play a full match on the Easy difficulty, since the AI opponent won't make any difficult shots or shots that require much movement, enabling you to basically stand still in the middle and keep pressing the button for smashing the ball back. While this does technically mean that you can actually complete the entire game (at least in single-player on the easy difficulty setting), for the end-user, the game is unplayable since no-one would be capable of playing the game in that state for any reasonable amount of time or even enjoy playing the game in that state. Further, even if they would, luck would play a large role in it since depending on what court you're currently on, where you move etcetera heavily influences how little of the playing field you can see, rendering it in practice (even if not in theory) unplayable. This, to me (and I obviously admit I might be alone in thinking so) makes the game undeserving of a three-star rating (using the earlier discussed wording(s)), even if it is ''technically qualified for such a rating'' if going by wording alone. I'm not saying I have a perfect fix for this (though a quick-fix would obviously be to somehow point out/add in that a 3-star rating still doesn't mean that the game is actually enjoyable/playable), just that it is a serious problem that ought to be taken into account; perhaps the experience of the end-user should be taken into account in general somehow, e.g. in the sense that "playable" means that an end-user could reasonably be expected to play and enjoy the game and be capable of playing it to it's end, as opposed to meaning that it is technically/theoretically possible to play through the entire game without it crashing... Something along those lines? [[User:Incassum|incassum]] ([[User talk:Incassum|talk]]) 21:00, 14 January 2014 (CET)


=== Wii Network compatibility ===
:: Purged out the unused images. [[User:Kolano|Kolano]] ([[User talk:Kolano|talk]]) 06:52, 13 March 2017 (CET)
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? [[User:Jhonn|Jhonn]] ([[User talk: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? - [[User:MaJoR|MaJoR]] ([[User talk: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. [[User:Kolano|Kolano]] ([[User talk: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? [[User:Jhonn|Jhonn]] ([[User talk: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.[[User:Kolano|Kolano]] ([[User talk: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"
[[User:Kolano|Kolano]] ([[User talk:Kolano|talk]]) 22:01, 28 August 2013 (CEST)

Revision as of 19:03, 14 January 2018

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

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|<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). - 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)

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)

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 PR #5763, 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)