Difference between revisions of "Project:General Discussions"

From Dolphin Emulator Wiki
Jump to: navigation, search
(Recent Discussions)
(MD5 / GameID capture: add note that dolphin itself now checks hashes against redump to confirm dumps)
 
(115 intermediate revisions by 8 users not shown)
Line 4: Line 4:
 
=== Global Replacement Request ===
 
=== Global Replacement Request ===
 
A spot to capture global replacement requests:
 
A spot to capture global replacement requests:
* == Problems == > == <span title="Resolved problems are listed only for one prior release version.">Current Problems</span> ==: Aligning with wiki policies that purge older resolved problem reports. [[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)
 
* Update testing/entry template to always include "tester=" field. [[User:Kolano|Kolano]] ([[User talk:Kolano|talk]]) 01:36, 29 May 2015 (CEST)
  
=== Performance Addition to Game Wiki Pages ===
+
=== Titles without GameINI entries vs Rating ===
As Kolano said in his edit, performance is not the goal of this wiki. The default settings are already the best balance of speed and compatibility, the wiki exists to help people know what those settings are and what they mean and to catalog problems. Users can break things on their own juuuust fine! While I'm at it, why did you place notes throughout the page? You aren't intending to have that in the live version are you? - [[User:MaJoR|MaJoR]] ([[User talk:MaJoR|talk]]) 17:11, 26 April 2015 (CEST)
+
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)
:It's a WIP, or RIP really (revision in progress), that I will propose along with the other proposal I am working on. The goal is to make pages easier to read and to appeal to both audiences; people who want performance over emulation accuracy '''and''' people who want emulation accuracy over performance. --[[User:Wildgoosespeeder|Wildgoosespeeder]] ([[User talk:Wildgoosespeeder|talk]]) 22:14, 26 April 2015 (CEST)
 
::I think you are misunderstanding the approach the wiki is taking. Our job is not to balance speed and performance, but to inform the user of accuracy issues and problems and let them make their own decision on how to balance their own needs. This is the only way the wiki can remain objective - "balance" would vary depending on the user's system, the game and problem at hand, and their own personal opinion. If you make a post saying that a certain setup is the best balance, and I disagree with that, who's right? No one is! It's impossible to resolve, since it's all subjective. But if it's accuracy related, we can test it, confirm it, and apply it. By sticking to accuracy it gives us a reasonable way to make a reliable wiki, and the users can be informed about what a problem is, how to avoid it, and the costs it will take; allowing them to make their own decisions on whether those costs are worth it to them. That said, we do try to inform them of the costs, especially if it is something nasty like Single Core. - [[User:MaJoR|MaJoR]] ([[User talk:MaJoR|talk]]) 08:36, 29 April 2015 (CEST)
 
::::I think you misunderstanding what I am proposing. I am not proposing accuracy loss. I am proposing an additional section that documents performance tweaks as well as preserve the section for accuracy. To my understanding, the current way pushes accuracy as the forefront while performance is an afterthought. The performance tweaks are there, yes, but are "camouflaged". Somewhat harder to see. Look at [[Interactive Multi Game Demo Disc 2001-10/sandbox|the sandbox]] again. Maybe you will understand what I am suggesting. Most people will want to play their games with minimal distractions, not see how accurately Dolphin can emulate their favorite games. Some do want an accurate emulator. I'm proposing satisfying both parties, not just one or the other. I am not suggesting a middle ground either. --[[User:Wildgoosespeeder|Wildgoosespeeder]] ([[User talk:Wildgoosespeeder|talk]]) 09:28, 29 April 2015 (CEST)
 
::I'm somewhat supportive of adding a performance tweaks section, but there would need to be some fairly strict guidelines on the sorts of things we'd capture there. For instance it may be nice to work out games that don't use EFB, and can safely disable EFB effects (something it might be nice to be able to effect via the game ini's actually). Having some coverage of issues raised by various performance tweaks might also help avoid those getting mixed in as reported bugs. There's also the subject of visual tweaks, where we might cover things like compatibility of AA / Antis-tropic / Force Filter settings (another thing it might be nice to be able to disable via ini) and/or provide a spot for HD texture pack details.
 
::Per concerns already raised, we should take this slowly though to try to avoid it becoming messy. [[User:Kolano|Kolano]] ([[User talk:Kolano|talk]]) 09:48, 29 April 2015 (CEST)
 
::Honestly I don't really see much point... Games that need DSP LLE are marked as such, those that need EFB to Ram are marked as such, so saying "this game is fine with EFB to Texture" is just redundant. This is why we removed config entries that recommended EFB to Texture and created the best accuracy rule in the first place. Well, that and people filling out a page with their favorite settings irregardless of how it broke things! The accuracy rule gave us a standard of objectivity that kept favorite settings and things that can be reproduced away from the wiki, and helped it be as useful as it is. Games that are ok without EFB is a valid point... if users could disable efb copies anymore! Most of the dumb settings like that have been removed. :P And if antialiasing or AF or something breaks something or is needed, it's already mentioned (see skyward sword). "Camouflaged" it may be, but all of the information is there, so honestly I think all of this is covered already by existing conventions. If a game needs something that's intensive, it's mentioned, and if it doesn't, use what runs fastest (which is already the default...) - [[User:MaJoR|MaJoR]] ([[User talk:MaJoR|talk]]) 02:51, 3 May 2015 (CEST)
 
:::On a final note, any performance additions to this wiki should follow the objectivity rule: they would have to measurable and reproducible. Part of my resistance to this idea is just how badly things were with performance in the past, because people would put things up saying it's "faster" and then we'd kill it for being dumb and they'd put it back '''insisting''' it is better and must be on the page! We were only able to clean that up by implementing the accuracy and objectivity concepts. So I'm definitely scared by all of this performance talk, as it is trying to bring back some of the things that let crap enter this wiki. While I am not very open to it, at the very least it would need to follow objectivity standards, and have a plan prepared ahead of time for dealing with "but these are the best settings!" people. ...and there is also the fact that we can't test every game and every post that comes through, and this performance thing could let users sneak more weird settings in since it's harder to understand performance impacts since it varies so much with hardware. Ok yea I'm still against it. But my point is, objectivity rules and preparations against ignorant users must be involved in this! - [[User:MaJoR|MaJoR]] ([[User talk:MaJoR|talk]]) 02:58, 3 May 2015 (CEST)
 
::::One thing I noticed that Dolphin doesn't do is have a reset button or something to restore default settings. Sure, there is dialog for the recommended setting if the user is unsure of the default setting, but no convenient button. If a button were implemented, you could use that to further enforce the importance of first testing with default settings vs. them deviating from the default settings where the game had bugs running under Dolphin. That way real bugs are filtered away from false bugs induced by the user. --[[User:Wildgoosespeeder|Wildgoosespeeder]] ([[User talk:Wildgoosespeeder|talk]]) 04:40, 10 May 2015 (CEST)
 
:::::In general and in my opinion, Dolphin and its support pages aren't the most user-friendly I have used. It seems to be geared towards enthusiasts. I can use it and understand what I need to know to make the emulator work, but I don't know if the average user will understand like we do. That is the root concern I have and I am trying to address it one problem at a time and see what you guys think of the solution I came up with. I have a lot of practice with this in general. I hope to be of good help by providing valuable feedback! --[[User:Wildgoosespeeder|Wildgoosespeeder]] ([[User talk:Wildgoosespeeder|talk]]) 04:40, 10 May 2015 (CEST)
 
::::::Well... the goal of the wiki is to educate people, and we tell them how to do things, how to fix problems, etc etc while letting them make their own decisions on techniques and performance. And the data is kept objective so it can be repeatable and sustainable long term. Not every user is going to want to know why this or that does this and why it fixes this bug, but the emulator has many support mechanisms to help those users already. The wiki serves as the last part of a chain, not the first. GameINIs catch most things, the forums/irc/reddit and other support catches the rest, and then we inform the enthusiasts that provide support as well as users who want to learn and grow on their own. There are many layers of support, and we are the most technical. '''And that's ok!''' It is what wikis are best at: education. The wiki serves as a long term database of technical information regarding the impact of features and changes in the emulator and ways to work around various issues, something that none of the other support mechanisms can do effectively. I'm totally open to improving our ability to educate, but you need to understand our resistance: what we have works, and it was the first (if not the only, I don't know of any others) emulator wiki to achieve this kind of reliability. The Dolphin wiki has succeeded because of the users willing to learn and share that knowledge, but also because of the curators who have worked hard to develop rules and structures that foster the usefulness of the wiki and encourage users to contribute. The decisions we admins have made over the years, such as the objectivity/reproducibility standard, were made to create something that is reliable and informative to end users but sustainable to wiki editors and admins. It is a very careful balancing act, but it's working! So there is going to be some resistance when a single new person comes out of the blue and proposes sweeping changes. While that may be a little frustrating for you, please understand that we're trying to listen and understand the new ideas so we can incorporate things that will improve the wiki, but also protect the systems that have worked so that the changes improve the wiki and not make it worse. To that end, you have repeatedly said that you have worked in other sites that work better, but you have never shared them. If you could show them, it would really help us understand where you are coming from, and help us pick up good ideas from them on our own. Would you mind sharing those references? - [[User:MaJoR|MaJoR]] ([[User talk:MaJoR|talk]]) 09:51, 10 May 2015 (CEST)
 
:::::::I never mentioned I contributed to other websites the way you are implying. I have contributed, yes, but never pushed dramatic changes or ideas to how something could work better for a website. Usually it's already good as-is. The Dolphin website is the first time I felt I could do it more confidently. As for making things more user-friendly, they are mostly related to designing interfaces for sample programs I have made that I never made the source code public. I do have them, but I haven't really bothered to go through my various projects (big or small). I don't have a website to showcase them. I find designing a website from scratch cumbersome. If I have predesigned assets to work with and an easy drop-in system, like using Visual C# 2008/2010, then I can design something rather easily. It's like building with LEGOS vs. drawing a picture for me. LEGOS come easier for me. I have the pieces here on this website, just not the ability to create them. I just find the pieces are not being used most effectively. --[[User:Wildgoosespeeder|Wildgoosespeeder]] ([[User talk:Wildgoosespeeder|talk]]) 10:30, 10 May 2015 (CEST)
 
  
=== Game .ini Documentation? ===
+
: 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.
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.
+
: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)
  
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.
+
:: 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)
  
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:
+
:: 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? - [[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.
  
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.
+
:: 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)
  
Pros:
+
: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)
  
*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.
+
=== 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)
 +
: 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)
 +
::: 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)
  
*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.
+
:::: 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)
  
*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.
+
::::: 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. [[User:Kolano|Kolano]] ([[User talk:Kolano|talk]]) 06:10, 27 November 2016 (CET)
  
Cons:
+
:::::: 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:mbc07|mbc07]] ([[User talk:mbc07|talk]]) 06:52, 27 November 2016 (CET)
  
*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.
+
::::::: 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. [[User:Lucario|Lucario]] ([[User talk:Lucario|talk]]) 05:52, 28 November 2016 (CET)
  
*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.
+
:::::::: 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. [[User:Lucario|Lucario]] ([[User talk:Lucario|talk]]) 20:42, 28 November 2016 (CET)
  
*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.
+
::::::::: Okay, before continuing, let's clear some points:
  
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)
+
::::::::: * '''Calling {{tl|GlobalProblems}} inside {{tl|Problems}} and doing RegExp on their entries:''' I might have overlooked but that seems exactly what you did in the recent changes to {{tl|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 {{tl|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.
  
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)
+
::::::::: 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)
  
 +
:::::::::: 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 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.
+
:::::::::: I'm fine with Problem template going official now. [[User:Lucario|Lucario]] ([[User talk:Lucario|talk]]) 23:16, 29 November 2016 (CET)
 
 
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 89: 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 105: 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 ===
+
Dolphin itself now directly confirms GameCube (and eventually Wii) IDs against Redump's public IDs as of {{revision|5.0-11054}}. That's a pretty good stamp of approval for Redump, but also kind of eliminates the need to keep MD5s here at the same time. Just adding this as an update. - [[User:Xerxes|Xerxes]] ([[User talk:Xerxes|talk]]) 02:00, 25 October 2019 (CEST)
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?
 
 
 
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.
 
 
 
What do you guys think? - [[User:MaJoR|MaJoR]] ([[User talk:MaJoR|talk]]) 08:20, 3 August 2014 (CEST)
 
 
 
: 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:
 
 
 
*is it Perfect if a super tiny non-user noticeable bug remains? Example - {{issue|6398}}.
 
*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.
 
 
 
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)
 
 
 
: 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]])
 
:: 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'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.
 
: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 ===
 
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 ===
 
=== Error with Slash in Search ===
Using a forward slash in a search term (i.e. "NA/EU") results in a set of Wiki errors...
+
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"
 
"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)
 
[[User:Kolano|Kolano]] ([[User talk: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. [[User:Kolano|Kolano]] ([[User talk:Kolano|talk]]) 07:04, 13 March 2017 (CET)
  
 
== Recent Discussions ==
 
== 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.
 
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.
  
=== 16:9 and F-Zero GX's custom cars problem restoration ===
+
=== Proposed expansion for Wii GameIDs ===
Since the edit summary has very little space, I'm going to fill in the details here. Both of these problems (and the powersliding bug) are problems that users encountered in the emulator and asked about on the forums or made issue reports about. The custom car bug was frequently encountered and everyone thought it was Dolphin's fault, and many users have been caught running this game with widescreen hacks and asking for help with bugs! The problems are there to preemptively inform them so they will not experience the problem in the first place. They are in the problems area because to a user, it is a problem, and the problems area is where solutions to problems lie. They are however on the bottom, since they are the least important. As for 16:9 being in enhancements, Lucario's logic is not entirely wrong, as you have to do it on the console so it is an issue that would be encountered there as well. But it is wrong in that it can't be an enhancement if it is a feature of the game and not something dolphin is adding to it. Furthermore, the problem of users using the widescreen hack and then having problems with it IS a dolphin-unique problem, and this is meant to address that specifically. So the problems area is the spot it belongs in most. - [[User:MaJoR|MaJoR]] ([[User talk:MaJoR|talk]]) 07:48, 4 November 2015 (CET)
+
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)
:I haven't thought of the part where users should turn "widescreen hack" off when using the widescreen mode in the game, hence the problem on emulation side where the widescreen hack exist. I'll give you that. I'm also thinking of a new section titled "User Errors" where we can list common errors that was on the user's side. Then the custom car problem can go there and the two players one ctrl problem in Super Smash Bros. Brawl and possibly others. What's your thoughts on this? [[User:Lucario|Lucario]] ([[User talk:Lucario|talk]]) 08:50, 4 November 2015 (CET)
 
::Hmm... I think a new section is a good idea! But I'm not sure "Users Errors" is a good naming for it though... What about bugs that happen in the game that dolphin recreates, but that users think are actually dolphin problems? See the F-Zero GX powersliding bug, star fox adventures and super mario galaxy reflections, etc etc. Where would they go? So a different term might be a good idea... - [[User:MaJoR|MaJoR]] ([[User talk:MaJoR|talk]]) 09:58, 4 November 2015 (CET)
 
:::Major raises a good point here. I would like to be consistent in how we handle things, so many of these non-emu bugs have been irksome in the Problems sections. Perhaps "Non-Emulation Problems" would be a inoffensive title for these. [[User:Kolano|Kolano]] ([[User talk:Kolano|talk]]) 10:05, 4 November 2015 (CET)
 
::::"Non-Emulation Problems" sounds better and it can cover more problems above, but doesn't felt right for certain kinds of problem, such as the two players and one controller in SSBB. Dolphin is still at fault for allowing the different controller settings to use the same device twice. I was thinking of a less technical term and I came up with probably the best term for all of these problems! "Common Misconceptions"?
 
::::On a second thought, I'm viewing the two players one controller as a real problem and that it should stay under the problem section. I can't think of any more user problems that "Non-Emulation Problems" can't cover. Either that or "Common Misconceptions", or we should continue to think of a better term that covers the user problem and sometime both user and Dolphin problem to some extent? [[User:Lucario|Lucario]] ([[User talk:Lucario|talk]]) 11:55, 4 November 2015 (CET)
 
::::"Emulation Information and Misconceptions"? [[User:Lucario|Lucario]] ([[User talk:Lucario|talk]]) 12:58, 4 November 2015 (CET)
 
:::::Just a heads-up, two players on one controller does fall in the new section, SSBB allows mixing Wiimotes with GC Controllers in real hardware, it's not Dolphin fault if the user configured the same bindings for both GCPad and emulated Wiimote. This also covers cases like [[Tatsunoko vs. Capcom: Ultimate All-Stars]] (which clearly says at the beginning that you can't use a Wiimote while a GC controller is plugged) and [[Sonic Riders: Zero Gravity]] (which already have a problem entry for that issue -- it should go in a new section). Said that, "Emulation Info" sounds kinda wrong for me (native 16:9 and mixing controllers can be done in real hardware too) so I would choose Common Misconceptions/Mistakes. And what about listing that section before Problems/Global Problems? Users having those common issues would quickly find the info they need without reading/rolling through all other problems (useful in pages with long problems, like F-Zero GX or SSBB). Thoughts? - [[User:Jhonn|Jhonn]] ([[User talk:Jhonn|talk]])
 
::::::I like "False Problems". Why? This excludes ''16:9 GCN'' because this is not a problem on any level, isn't an enhancement as defined by Dolphin emulator staff, and it sets up [[Template:WidescreenGCN]] better. --[[User:Wildgoosespeeder|Wildgoosespeeder]] ([[User talk:Wildgoosespeeder|talk]]) 21:16, 5 November 2015 (CET)
 
::::::Also there are images in [[F-Zero GX#Emulation Information]] section. Since they aren't bug images in the Dolphin sense, these images need to be categorized differently. --[[User:Wildgoosespeeder|Wildgoosespeeder]] ([[User talk:Wildgoosespeeder|talk]]) 21:42, 5 November 2015 (CET)
 
:::::::The reason I came up with "Emulation Information" is because it sounds more general than "Common Misconceptions". It's very general that even the "problem" section can move under it. I'm viewing "problem" and "emulation info" similar except that "emulation info" can arbitrarily accept more things, especially the misconceptions and others that Dolphin won't fix/help because of the user incompetence. I was thinking this might cover the font issue in Sonic game as well as it still requires users to dump the BIOS for best accuracy. Not something Dolphin can help. Though, Kolano was thinking otherwise. Maybe Kolano didn't see the "Emulation Information" an applicable term for the emulation problems as well as I do (until he read this?!). Also about moving that section up above the problem section, I'd say go for it! [[User:Lucario|Lucario]] ([[User talk:Lucario|talk]]) 22:43, 5 November 2015 (CET)
 
::::::::I think emulation issues is a perfectly good term. Its clear on what its purpose is without being so specific that it excludes too much. It's good! - [[User:MaJoR|MaJoR]] ([[User talk:MaJoR|talk]]) 11:33, 9 November 2015 (CET)
 
:::::::::Just to make sure, are you suggesting Emulation Issues or you're OK with Emulation Information?  - [[User:Jhonn|Jhonn]] ([[User talk:Jhonn|talk]])
 
::::::::::I'll give ''emulation information'' this: It '''is''' better than what we use to have but I still find it not the best solution to the problem. --[[User:Wildgoosespeeder|Wildgoosespeeder]] ([[User talk:Wildgoosespeeder|talk]]) 22:46, 9 November 2015 (CET)
 
:::::::::::Um... I don't care? By consensus the new section already is official, I was just asking MaJoR specifically about her thoughts of the new section naming. - [[User:Jhonn|Jhonn]] ([[User talk:Jhonn|talk]])
 
::::::::::::Oh! I'm sorry! I meant Emulation Information. - [[User:MaJoR|MaJoR]] ([[User talk:MaJoR|talk]]) 05:35, 10 November 2015 (CET)
 
  
=== 16:9 / Outdated Banners ===
+
: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?
Just saw [[F-Zero GX/sandbox]] and it's a big '''NO!''' from me:
 
* The banner is ugly and puts the 16:9 info before anything else as if it was the top priority info in a game page (which clearly it's not the case).
 
 
 
To finish, we already are discussing a new section for problems that aren't really problems (native 16:9, mixed controllers, etc), which looks waaaay better than this and just reinforces my point of you trying to fix a non-existent problem with this template. - [[User:Jhonn|Jhonn]] ([[User talk:Jhonn|talk]])
 
 
 
:The design of the banners are supposed to be an eyesore as it draws your attention to the article's lack of completeness (except for the 16:9 and dual-layer banners because that information needs to have more emphasis on them than having it be somewhere easily missed in the article). It's not supposed to be there but it is with a purpose. I'm trying to give incentive to make the article/section in question to keep it up-to-date. --[[User:Wildgoosespeeder|Wildgoosespeeder]] ([[User talk:Wildgoosespeeder|talk]]) 20:08, 7 November 2015 (CET)
 
 
 
:Keep in mind that [[F-Zero GX/sandbox]] is a proof of concept and should be regarded as a prototype of the idea. Refinements will be made on both a template format level and page layout level.
 
:* It might be ugly now but the idea behind banners is to be a sign with important information. The position it is located now may change later.
 
----
 
::<nowiki>*sigh*</nowiki> And not related to this but why you also want to convert problems into banners? Dual-Layer games already have its own category which is easy to reach from the bottom of the page, GC games with 16:9 native support already have an entry in problems section and in those cases both will be moved to the new Emulation Info/Common Misconceptions (or whatever name we choose) and can also be accessed through its own categories. And about your complaint regarding unnecessary edits, font problem in Sonic Mega Collection was moved back and forth because of my initial complaints about the subject but eventually settled in Problems section. How this template or your banners-that-go-before-anything-else would have improved this particular case? Just stop, you made an ugly proof of concept where I can't see any way to improve, nor it provides anything better than the new section we're discussing in [[Talk:F-Zero GX]], not to mention you didn't provide any feasible reason. Unless other admins (MaJoR, Kolano) or active members like Lucario weight in pointing something positive in favouring this approach, you can consider this whole "problem rating" thing something that won't go anywhere else besides the F-Zero GX sandbox. ''If it ain't broke, don't fix it'' - [[User:Jhonn|Jhonn]] ([[User talk:Jhonn|talk]])
 
----
 
::::*'''"Maybe it's better to also have in that Infobox the WidescreenGCN and DualLayerWiiDisc banners? That might be the happy middle ground that everyone will like when it comes to the Template:WidescreenGCN and Template:DualLayerWiiDiscs banners."''' - From all of this discussion that's the only thing you brought that may work, from my point of view. Again, those banner templates are completely unnecessary. First, banners won't look good inside the Infobox no matter how you design them, second, if we're going to put new things in Infobox we could just make the its template handle the categories for those cases as well (reinforcing there's no need for separate templates like WidescreenGCN and DualLayerWiiDisc) since it already handles lots of categories based on the info put in the Infobox. My approach to get those "notes" in the Infobox would be discrete icons with mouse-hover, like the peripherals section of [http://www.wiibrew.org/wiki/Homebrew_Browser any homebrew app in WiiBrew], they are discrete (unlikely banners) and doesn't disrupt content flow.
 
::::To finish, you still failed to provide any benefit of using {{tl|RatingProblemFix}} and none of the other active admins/members shared thoughts in favour of this template, so, still don't expect this template going anywhere else besides the sandboxes, as far as I'm concerned. And about Template:WidescreenGCN and Template:DualLayerWiiDiscs, they should go as well, I suggest you trying something like peripherals section of Homebrew Channel infobox. - [[User:Jhonn|Jhonn]] ([[User talk:Jhonn|talk]])
 
----
 
:::::* I have since revised the pages and cleaned up any ugliness based on your feedback.
 
:::::* Banners were updated and moved locations. I don't know what to tell you. Either you refuse to accept my answers or there is a true miscommunication going on here.
 
:::::* The ratings are there to quickly evaluate importance of certain settings deviating from the default. I don't mind talk pages but what I found kind of irritating was someone else not clear what the problems section was for.
 
:::::* Looked at the [[Project:Wiki Conventions#Problems|problems section]]. There is nothing about emulator vs. real hardware but rather formatting best practices for that section and talking about Dolphin's programming quirks. I rest my case.
 
:::::* The categories is still a disorganized mess and the emulation information section is still easy to miss (I still like ''False Problems'' because there is more precision with using that phrasing). The banners are there to make things easier to spot.
 
:::::* You keep taking my ideas as finalized when they are not even close to being final. That is why they are in a sandbox. Iteration is the key word here. This idea I have may go through several design iterations until it looks practical and noticeable.
 
:::::Overall, only you and [[User:Lucario|Lucario]] seem to have disapproval of my attempted improvements. [[User:Kolano|Kolano]] is showing concern but it seems he is willing to see how I revise my implementations to look nicer. --[[User:Wildgoosespeeder|Wildgoosespeeder]] ([[User talk:Wildgoosespeeder|talk]]) 05:20, 6 November 2015 (CET)
 
----
 
::::::* Those banners you've slapped into infobox still are ugly and takes a lot of space but already looks somewhat better than that ad-like thing in the top of the page. However, put two or more of those banners in the same infobox and you get an even messy and long infobox. As I said, change that to discrete icons with mouse-hover text ([http://www.wiibrew.org/wiki/Homebrew_Browser like the example I gave from WiiBrew]) if you ever want this going official (or provide us a concept better than WiiBrew example). And just get rid of those separate templates by putting its categorize-this-page thing directly in Infobox template, '''they're not necessary'''!
 
----
 
:::::::* I'm kind of concerned that if I do like WiiBrew, my current configuration will lose visibility of more vital information such as DVD9 and 16:9 GCN games as the icons are easily recognizable for peripherals that the app supports and not technical details. I really like how WiiBrew handles warning the user about NAND modifications in the [http://www.wiibrew.org/wiki/SaveGame_Manager_GX SaveGame Manager GX] example. I know the templates are unnecessary at this point but for the purposes right now, until I can settle on a design that works, it will be in that structure for now.
 
--[[User:Wildgoosespeeder|Wildgoosespeeder]] ([[User talk:Wildgoosespeeder|talk]]) 21:44, 6 November 2015 (CET)
 
----
 
::::::::* That's exactly my point, that "vital" information isn't that important (especially in the infobox), the icons with mouse-hover still looks like the best approach for me (especially when this kind of info will probably be detailed in the new Emu Info section as well). You can try a "NAND Warning from WiiBrew" concept to show us how they would look, just don't forget they use a slightly small font and no icons at all (and even that, still draws more attention than it should, in my opinion). [[User:Jhonn|Jhonn]] ([[User talk:Jhonn|talk]])
 
----
 
:::::::::* [[Template:DualLayerWiiDiscs]] is pretty vital for some games emulating accurately while [[Template:WidescreenGCN]] is only vital to those who want their GCN games in widescreen and might be misinformed about the select GCN games that support it natively.
 
:::::::::* I consider each mentioning a part of the iteration process. My initial idea was to include a section about performance over accuracy in conjunction with the current problem section that is about accuracy over performance. I consider my ratings idea a second form of my idea where the advancement is not requiring a redundant section. Instead of rejecting the idea outright, hypothetically assume that if these changes were to go in effect, what would make them more appealing? I need feedback on that and you are failing to supply me with that. Who knows? Maybe my efforts are a waste of time. I don't know for sure because it's too early to tell. I don't think so because I do believe the core idea I have can be useful for Dolphin Wiki users, even though it's current appearance may not be.
 
:::::::::* I'm pretty much done with my ratings idea. I need more feedback to further refine the idea. Telling me to quit working on it isn't useful in the slightest. --[[User:Wildgoosespeeder|Wildgoosespeeder]] ([[User talk:Wildgoosespeeder|talk]]) 04:13, 7 November 2015 (CET)
 
----
 
:::::::::* No, they are not. If you incorrectly dump a dual-layer game, in most cases the game will instantly crash Dolphin when accessing specific areas/stages or won't even boot, clearly indicating something is veery wrong with your dump. The only exception to this case is Super Smash Bros Brawl, where everything despite Subspace Emissary movies will work with a incorrect dump, but it's already noted on its own entry (currently in Problems section, but it'll transition to the new section eventually).
 
:::::::::::It's not really correct to say the Super Smash Bros Brawl issue is an "incorrect dump" it's a correct dump of a hacked version of the game modified to fit on a single layer disc.
 
::::::::::::The section I created refers to unaltered official copies of SSBB in ISO form straight from the Nintendo warehouse. Having a hacked version run on Dolphin isn't a priority as I have come to understand the current focus of its development. --[[User:Wildgoosespeeder|Wildgoosespeeder]] ([[User talk:Wildgoosespeeder|talk]]) 20:36, 7 November 2015 (CET)
 
 
 
=== Formatting Suggestion for Compilation Discs ===
 
I noticed some articles, such as [[Intellivision Lives!]], [[Sonic Mega Collection]], and [[Interactive Multi Game Demo Disc 2001-10]], are hard to read what the compilation consists of. I have worked on a table consisting of MediaWiki code and no templates that addresses that issue and I think I found a clear winner, found [[Interactive_Multi_Game_Demo_Disc_2001-10/sandbox|here]] taking [[Interactive Multi Game Demo Disc 2001-10]] as a base. Should I start implementing this for every article about compilation discs contents or does the table need work? --[[User:Wildgoosespeeder|Wildgoosespeeder]] ([[User talk:Wildgoosespeeder|talk]]) 23:52, 23 April 2015 (CEST)
 
 
 
:It's Ok for me as it is now, my only requirement is converting your table into a template before implementing it everywhere: theoretically it's something we're gonna use in various pages (assuming everyone else agrees and we actually implement it), so, making it as a template allow us doing quick edits in the future that would reflect in every page using this box. - [[User:Jhonn|Jhonn]] ([[User talk:Jhonn|talk]])
 
 
 
 
 
=== Emulation Information Position ===
 
Lucario, in his recent edits, put the Emulation Information section above problems, while I have historically put them below. It is something of a subjective decision, but most of the time the problems are minor, and not as critical as emulation bugs, so historically, by our conventions, they have been placed below other problems. So I assumed based on that that the Emulation Information would be placed beneath problems, and sometimes they were, and other times they weren't depending on who entered it. I was going to just move it all, but this could cause issues in the future, so we should probably get some consensus established. What location for the emulation information do you guys prefer? - [[User:MaJoR|MaJoR]] ([[User talk:MaJoR|talk]]) 10:46, 17 November 2015 (CET)
 
: As far as I remember, we sticked with Emulation Information above problems but I'm not sure either (would have to dig into that long discussions -- too lazy to do that now). So, I think we should put it above. Yes, they're minor, but it's also some very common problems, thus, it's what the user wold read first if they have issues with a bad dump (SSBB case), problems with widescreen hack (GC games with native support) or controller issues (Wii games), providing information quicker instead of rolling through the entire problems section, that can take a big amount of space (e.g. Wind Waker, which have lots of problems listed). And since emulation information isn't a section that's going to be crowded (so far I haven't saw any page with more than two small entries) I think it's a win-win case (the full page would be something like Emu Info => Global Problems => Problems => Enhancements => Config => Version Compat => Testing => Gameplay Screens => Gameplay Videos => Navigation -- Emu Info and Enhancements only present in pages that have suitable entries, Global Problems only in VC pages and Navigation only where applicable). - [[User:Jhonn|Jhonn]] ([[User talk:Jhonn|talk]])
 
 
 
:It's position doesn't bother me one way or the other. To hopefully build consensus I'll say list them first. [[User:Kolano|Kolano]] ([[User talk:Kolano|talk]]) 15:40, 17 November 2015 (CET)
 
 
 
::Well, I don't entirely agree, but you have reasonable thought behind it, and Kolano got me :P. The top it is! - [[User:MaJoR|MaJoR]] ([[User talk:MaJoR|talk]]) 11:32, 18 November 2015 (CET)
 
 
 
 
 
=== Config Template Slight Wording Tweak ===
 
After having a talk with [[User talk:Kolano#Edit You Did|Kolano]] about having my confusion cleared up what should be included in the configuration section of each disc wiki page, I think [[Template:Config|the template]] should read "Only configuration options for the best ''accuracy'' where they deviate from defaults are listed" instead of "Only configuration options for the best ''compatibility'' where they deviate from defaults are listed" (without italics). Anyone agree? --[[User:Wildgoosespeeder|Wildgoosespeeder]] ([[User talk:Wildgoosespeeder|talk]]) 21:11, 24 April 2015 (CEST)
 
:Compatibility = accuracy, pretty much. This wiki uses the term compatibility because the word is used alway used to describe how well a game plays in an emulator. And the language is consistent and pervasive throughout the wiki and the site: "Compatibility Wiki" with "Compatibility Lists" (see the left sidebar) and "Compatibility Ratings". Even the main page has a compatibility section with compatibility ratings from this wiki! It's all tied into larger emulation concepts of what the word compatibility means for an emulator, and I think it's still a valid term. We could change it to accuracy just there for clarity, but then it becomes out of sync with the terminology in the rest of the wiki, which imo should remain compatibility. I'm not like completely opposed or anything, but I'm not really in favor of this idea. Anyone familiar with emulation should get what compatibility is pretty quickly. - [[User:MaJoR|MaJoR]] ([[User talk:MaJoR|talk]]) 08:44, 29 April 2015 (CEST)
 
::As defined by Google: "A state in which two things are able to exist or occur together without problems or conflict." That doesn't describe accurate emulation because there are some problems even with that like speed loss. --[[User:Wildgoosespeeder|Wildgoosespeeder]] ([[User talk:Wildgoosespeeder|talk]]) 09:43, 29 April 2015 (CEST)
 
 
 
=== Regions Consistency ===
 
I think we should shorten the region code for Australia and Russia to AU and RU. There is currently no consistency with the others(JP,NA,EU,KO) being two letter codes. [[User:Zephyrsurfer|Zephyrsurfer]] ([[User talk:Zephyrsurfer|talk]]) 09:48, 8 November 2014 (CET)
 
 
 
=== Influx of Bot Generated Accounts ===
 
I think we had discussed previously the accounts that seem to be generated by bots of some sort. The number of accounts registered is starting to get a bit ridiculous, even if there are no follow-up spam posts. Is the captcha/other constraints used configurable enough that they could be modified to stem the flow a bit? [[User:Kolano|Kolano]] ([[User talk:Kolano|talk]]) 17:39, 8 March 2014 (CET)
 
 
 
It is configurable, but what do we do? It appears as though they have figured out our captcha trick for account creation but then get hit on the post captcha, so we just get tons of random accounts. But we don't even have access to IP addresses to find similarities for banning :(. Do you have any ideas? - [[User:MaJoR|MaJoR]] ([[User talk:MaJoR|talk]]) 09:52, 9 March 2014 (CET)
 
 
 
I'd have a feeling that things aren't targeting this wiki specifically. Adding some additional custom query, even if it didn't change with each registration, in addition to the standard one provided by the captcha tool might cut things down. [[User:Kolano|Kolano]] ([[User talk:Kolano|talk]]) 17:18, 9 March 2014 (CET)
 
 
 
Agreed. But I still need something more specific... Are you talking about a second captcha just for signing on? Or just a new custom query for our existing captcha system? - [[User:MaJoR|MaJoR]] ([[User talk:MaJoR|talk]]) 23:00, 9 March 2014 (CET)
 
 
 
Wouldn't a simple solution do it? E.g. adding the "you need to type in the name of the emulator here" bit that we use for editing articles to the registration, and/or adding another captcha? That wouldn't be too complicated to implement, and is a good first attempt: if it doesn't succeed, ok, we'll have to look into some more "advanced" options, if it does, yay, simple solution to the problem. [[User:Incassum|incassum]] ([[User talk:Incassum|talk]]) 19:54, 10 March 2014 (CET)
 
 
 
"you need to type in the name of the emulator here" is already in the registration process. - [[User:MaJoR|MaJoR]] ([[User talk:MaJoR|talk]]) 03:38, 11 March 2014 (CET)
 
 
 
What about using more questions (randomly selecting one of them each time) or using a captcha method based on mouse input only, like these simple jigsaw puzzle based? Right now I remember of KeyCaptcha, but AFAIK it isn't free... [[User:Jhonn|Jhonn]] ([[User talk:Jhonn|talk]])
 
 
 
 
 
=== 4.0 is released! ===
 
Alright! 4.0 has been released! Well, you know what that means: CLEAN UP. Removing all of those old crossed out problems. I have a few other things I want to bring up though.
 
*New Logo - Yep, we have a new logo! Made by yours truly. It comes in blue and grey, so I feel like I need to ask... do you guys think blue is better, or do you like the grey?
 
*3.5-367 notice - We need to change that to a 4.0 announcement! Maybe I'll go ahead and do that.
 
*[[How to update Dolphin]], [[Installing Dolphin]] - Delete them, or remake them to fit the global user directory changes?
 
*D3D9 is going to go away. VERY SOON. That's going to be a royal nightmare for us... I'm not sure there is any preparations we can do. How do you guys think we should handle the transition?
 
Well I've been up to my neck helping out with the 4.0 transition, from the logo and themes to testing and helping out with a video that will be released soon. I'll be resting for a few days before I help out on a large scale. So what do you think about the things I brought up? - [[User:MaJoR|MaJoR]] ([[User talk:MaJoR|talk]]) 17:48, 22 September 2013 (CEST)
 
 
 
: OK, a few things here...
 
:* The new logo seems to be less tall than the old one, resulting in an excessive gap beneath the logo and the side-navigation.
 
:* I'd be OK with the blue logo version here, the Wiki could use some color.
 
:* We also need to consider revisions to the compatibility boxes to allow them to display the recent revision history in more detail (i.e. each px of the graph now covers 3+ revisions, so tightly packed release issues can get hidden. We also need to account for converting the 4.0-xxx release indicators into the simpler release counts used.
 
:* I revised the notice to use a proper link rather than just text URL. Not clear if there was a reason it had been done that way, or delroth was just unfamiliar with the wiki markup.
 
:* Regarding DX9, we should be able to add a check into the Config template to identify pages indicating DX9 stuff. But it will be a big clean-up, and likely to lead to feuds with users on XP, that can't use newer DX's.
 
[[User:Kolano|Kolano]] ([[User talk:Kolano|talk]]) 19:45, 22 September 2013 (CEST)
 
-------
 
:* I like more the blue version of the new logo...
 
:* Should we consider deleting [[Performance Guide]] too, or perhaps pointing to Dolphin manual instead? [[How to update Dolphin]] it's kinda useless now, since you just need to obtain a new copy and by default everything will work because of the global directory. [[Installing Dolphin]] could be updated with instructions for stable releases and development builds...
 
:* The only issue I see with DX9 removal is updating the wiki, any user running Windows XP with Dolphin probably have a GPU that meets the minimum requirements for running the emulator, so they can just use OpenGL. Also, Windows XP support from Microsoft will be ended soon (April 2014), so, Dolphin users with WinXP will have to deal with it (updating the system or using an older version -- a lot of softwares stopped being updated from WinXP already)
 
:* Couldn't we ask delroth to just run a bot that searches all game pages for entries with <code><nowiki><s> </s></nowiki></code> and delete them?
 
I'm going to help soon, right now my highest priority is updating the (still unofficial) [http://portableapps.com/node/35614 portable version] at PortableApps.com - [[User:Jhonn|Jhonn]] ([[User talk:Jhonn|talk]])
 
-------
 
A critical issue slipped into 4.0: Single Core crashes. So they are releasing 4.0.1 in a few hours to replace 4.0. This is certainly going to throw a wrench into the version compatibility graph...
 
*Blue logo - Cool. Tomorrow I'll ask delroth to update it. As for the spacing, the logo is trimmed, so it's on mediawiki's side. Honestly, I like it. The logo has prominence that way.
 
*The Dolphin Manual isn't completed yet, sadly. With 4.0 and that pesty "real life" hitting me at the same time I've been crazy busy, and so has shonumi. :( We'll need to patch the performance guide yet again, even though it's stupid. - [[User:MaJoR|MaJoR]] ([[User talk:MaJoR|talk]]) 04:28, 23 September 2013 (CEST)
 
 
 
=== Category Format Clean-up ===
 
Categories have been put together in a fairly ad-hoc way. That has resulted in a few issues...
 
*Overlaps in categories for different usage: Arcade platform vs Arcade genre
 
*Different capitalization styles (All initial caps vs just first initial cap)
 
*General sloppiness across category naming
 
 
 
I think I'd like to clean such up, standardizing to something like "<Category Grouping>:<Category Identifier>" so we'd have categories like "Platform: Arcade", "Genre: Arcade", "Publisher: Nintendo", "Input Supported: Wii Remote", "Initial Release Year: 2011". A lot of such can be performed with changes to Infobox, but some things like the platform/image categories would require many edits. I'd probably want some automated assistance with that. Feedback would be appreciated.[[User:Kolano|Kolano]] ([[User talk:Kolano|talk]]) 08:28, 5 September 2013 (CEST)
 
 
 
:I agree with this. Just the result of lots of manual editing over time. I trust you'll handle it well. If I see anything I don't like I'll whine. When you email delroth the instructions give us a headsup here please. - [[User:MaJoR|MaJoR]] ([[User talk:MaJoR|talk]]) 12:28, 6 September 2013 (CEST)
 
 
 
::OK, initial change associated with this has been enacted. Will take a while for the initial template changes to percolate through the wiki. Should cover most of the categories outside of platforms, and any other direct in-page ones. Will likely start on the red-link elimination tomorrow (i.e. the 17th), not sure if there is any automation that could help with such. A few related issues:
 
::* One issue with the revised category names, is that although things still sort alphabetically. Since all categories in a group are prefixed with the same term, they no longer group together by letter. I think I may revise things to use a postfix instead to address that. Such will make the global categories listing messier (since groups won't group together), but would improve the display of individual category pages. Please let me know your thoughts.
 
::* When we transition the Platform categories, do we just want to move toward listing the platforms in the infobox, rather than as a separate item? [[User:Kolano|Kolano]] ([[User talk:Kolano|talk]]) 09:00, 17 September 2013 (CEST)
 
:::Fine with me. I don't know anything regarding the revised category names grouping though, sorry. - [[User:MaJoR|MaJoR]] ([[User talk:MaJoR|talk]]) 04:58, 18 September 2013 (CEST)
 
 
 
This is almost complete now. Unfortunately I failed to add categories to the newly created categories, so I need to do one more pass to add appropriate ones in. [[User:Kolano|Kolano]] ([[User talk:Kolano|talk]]) 04:50, 17 October 2013 (CEST)
 
 
 
OK, this should be done now, outside of the platform migration to the infoboxes. [[User:Kolano|Kolano]] ([[User talk:Kolano|talk]]) 07:20, 17 October 2013 (CEST)
 
 
 
=== Infobox Enlinkening ===
 
OK, I think I'm about done with my edits to how infobox generated categories are handled and the addition of linkages to those generated categories. Sorry for the recent spew of edits related to such without much discussion. Please do let me know your thoughts. [[User:Kolano|Kolano]] ([[User talk:Kolano|talk]]) 06:11, 5 September 2013 (CEST)
 
 
 
:Looks good to me. I don't know about the internals of how it works, but I don't care about that :P. From an end user standpoint it looks and works great. That's what counts. - [[User:MaJoR|MaJoR]] ([[User talk:MaJoR|talk]]) 12:28, 6 September 2013 (CEST)
 
 
 
=== Mass redirecting gameids ===
 
Just a quick heads up: I've been running a script to automatically add about 500 missing gameid redirects (thanks to skid_au for the data!). See https://wiki.dolphin-emu.org/index.php?title=Special:RecentChanges&limit=500&hidebots=0 . It should be safe but if you notice anything weird, please tell me so I make it better next time.
 
 
 
I'll also squash some double redirects while I'm at it. [[User:Delroth|delroth]] ([[User talk:Delroth|talk]]) 14:16, 25 August 2013 (CEST)
 
 
 
Just adding a quick note here, that we likely need to run through the process that generated the GameID redirects initially again, as well as generally identifying where they are missing, since there are likely a variety of recently added games/pages without them now. [[User:Kolano|Kolano]] ([[User talk:Kolano|talk]]) 07:14, 7 November 2014 (CET)
 
 
 
=== Global Problems behavior ===
 
Ok, I worked on it today and now I have something to show to you, so we can decide if the template is going to work that way and so see if everyone agree. First of, the template is still WIP, so, the current code is messy and the documentation is missing. I'm having a lot of issues with empty space, but I'll try to fix that soon. Right now, the template are working this way:
 
* Global Problems of all VC pages are shown in the Main [[Virtual Console]] page.
 
* Specific problems of that platform are shown in the list of that platform.
 
* In the lists, the Global Problems section is ALWAYS shown, even if no problems exist.
 
* In the game pages, the "Global Problems" section are shown only if at least 1 global VC problem or 1 platform specific global problem exist. Otherwise this section is hidden.
 
* The Global Problems section in a game page first list the platform specific issues and after that the global VC issues of {{tl|GlobalProblems/VirtualConsole}}, like this:
 
<pre>
 
=== Active platform-specific issue 1 ===
 
=== Active platform-specific issue 2 ===
 
[...]
 
=== Active platform-specific issue N ===
 
 
 
=== Active global VC issue 1 ===
 
=== Active global VC issue 2 ===
 
[...]
 
=== Active global VC issue N ===
 
=== <s> Fixed platform-specific issue 1 </s> ===
 
=== <s> Fixed platform-specific issue 2 </s> ===
 
[...]
 
=== <s> Fixed platform-specific issue N </s> ===
 
 
 
=== <s> Fixed global VC issue 1 </s> ===
 
=== <s> Fixed global VC issue 2 </s> ===
 
[...]
 
=== <s> Fixed global VC issue N </s> ===</pre>
 
It's a little redundant but this design make sure that all Dolphin users will see these problems, even people who jumps directly in the game page through the Wiki context menu present in Dolphin itself. Furthermore, [[The Legend of Zelda: Majora's Mask]] is already using the global template and I'm going to remove that "test issue" from the VC global templates soon, I need it for testing. Before committing this to the other platforms, I'll (try to) fix all spacing problems and make the template source more readable, but I need feedback here, any objection or suggestion? [[User:Jhonn|Jhonn]] ([[User talk:Jhonn|talk]])
 
:Forgot something, the placement: Global Problems should be before or after the Problems section? [[User:Jhonn|Jhonn]] ([[User talk:Jhonn|talk]])
 
::Before. The Problems section for most VC games will be blank, and 9 times out of 10 it will just be the Global Problems. Furthermore, it mirrors how it is on the game lists. Oh, and don't forget the helpers for new users. - [[User:MaJoR|MaJoR]] ([[User talk:MaJoR|talk]]) 06:32, 10 August 2013 (CEST)
 
----
 
So Jhonn, finished? It seems like you got it; it's fully functional and very easy to use. As far as I'm concerned, add documentation and you're done. Anything else you want to do with it before we put it everywhere? - [[User:MaJoR|MaJoR]] ([[User talk:MaJoR|talk]]) 10:18, 12 August 2013 (CEST)
 
: Yep, finished... I'll add the search-and-replace strings in [[Project:To Do]], so you could ask delroth for the script. If the automation fails, then tell us and we go in the manual way. [[User:Jhonn|Jhonn]] ([[User talk:Jhonn|talk]])
 
:: Done. A very small amount of pages already had GlobalProblems inclusions - these weren't modified, even when they were obsolete. I unfortunately don't have a list. [[User:Delroth|delroth]] ([[User talk:Delroth|talk]]) 21:33, 12 August 2013 (CEST)
 
::: Thanks delroth. Only two pages already had the GlobalProblems (I commited manually to test), so, no worry. I reverted some pages that we're using Arcade category but weren't Virtual Console Arcade games, so everything is perfect now. Thanks again... [[User:Jhonn|Jhonn]] ([[User talk:Jhonn|talk]])
 
 
 
=== Global Problems Template ===
 
Splitting this to get more attention. Well, I started coding the global problems template for VC games, and before I continue the work, I need to get opinion of you guys regarding how we'll handle the universal problems in every VC game page. First off, I fell this necessary because some users just jump directly in the game page through context menu option in the emulator or by the forum thread, so, we need to add the universal problems in the game page too. Regardless of what design we choose, we'll need to add a template call in every VC game page (yes, it's a booooring job that has to be done -- at least there aren't to much VC game pages created). But before I continue working in the template, we need to decide how we'll show this, and I have two suggestions: first, calling the template without an argument (eg. in a game page) create a section named "Global Problems", and parse the problems for that system. The second one, is adding the template call after the specific problems, this way, the global problems will just appear together with the specific problems. Do you guys have any other suggestion? What you prefer? I vote for the first one... [[User:Jhonn|Jhonn]] ([[User talk:Jhonn|talk]])
 
 
 
<s>I could ask delroth</s> I asked delroth about making a script for putting the global problems template into every VC game page. As soon as we get thing settled on how it should be used, he should be able to commit the global problems to every VC game page. To that end we might want to double check as make sure all the virtual console games are in [[:Category:Virtual Console]], as that's what I was going to suggest he use (unless you guys have a better idea?). As for the options, I vote for the first one. A "global problems" section in each game would be better; having the global problems inline could cause some confusion. - [[User:MaJoR|MaJoR]] ([[User talk:MaJoR|talk]]) 09:35, 3 August 2013 (CEST)
 
-----
 
Ok, if we're going to use the first suggestion, we'll need to add the following in every VC game page:
 
 
 
<pre>
 
{{GlobalProblems/<system>}} <!-- To edit the <system> VC Global Problems, navigate to "Template:GlobalProblems/<system>" (copy to the search box)-->
 
</pre>
 
 
 
This way I can code the template to only show the Global Problems section if there are global problems for that platform so I can get rid of the <no problems placeholder> -- any objections?
 
 
 
About the automation, I'm unsure if we can use [[:Category:Virtual Console]], because the text above changes from platform to platform... We need to replace <system> with N64 in N64 VC game pages, SNES in SNES, etc. Do we have category based on platform for the VC titles? If this doesn't work, I'm ok in doing this manually (we haven't a lot of VC game pages created, anyway)
 
 
 
Furthermore, the global problems will be shown before or after the specific problems? I think before is better, so we have Global Problems section (it'll show only if there are at least one global problem for that platform), and after that, the regular Problems section like we have now. What do you guys think? [[User:Jhonn|Jhonn]] ([[User talk:Jhonn|talk]])
 
 
 
----
 
 
 
You're right. Fortunately, every VC game has two categories: [[:Category:Virtual Console games]] and the system category, say, [[:Category:SNES games]]. We can use that to pick between the platforms. And I agree with you: putting global problems before the standard problems is probably the best option. Well, it seems like we agree, I don't know where Kolano is though... Well, I'd prefer to wait until Kolano chimes in. Or at least just wait a couple days then go with it.
 
 
 
Well, once we get everything settled, I can send delroth an email about the script. Or perhaps it's better if you do it Jhonn? You are more involved with the template. - [[User:MaJoR|MaJoR]] ([[User talk:MaJoR|talk]]) 04:36, 4 August 2013 (CEST)
 
:Well, I'll just wait a bit more to get Kolano opinion and then finish the template. After that we see how we'll handle the migration... [[User:Jhonn|Jhonn]] ([[User talk:Jhonn|talk]])
 
 
 
::I'm fine with the plan here. Though having some automated way of updating the VC pages would be nice, really there are rather few VC pages in total as of yet (only ~80), so a manual update wouldn't be too hard. [[User:Kolano|Kolano]] ([[User talk:Kolano|talk]]) 08:39, 4 August 2013 (CEST)
 
 
 
----
 
  
Alright, everyone seems fine with it, so I'm going to send the email to delroth. I'll recommend he use the system categories to know what to put where, and tell him to place it above the problems section. If anyone wants to do it manually they can just do it first. - [[User:MaJoR|MaJoR]] ([[User talk:MaJoR|talk]]) 06:13, 6 August 2013 (CEST)
+
: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)
  
=== Purge CPU Arch Indicators ===
+
::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)
I have been thinking of purging out the OS bit depth indicators (i.e. x86, x64, x86_64). They made sense back when x86 and x64 versions of Dolphin were offered, but now that we only support x64 I'm not clear that they do. Raising here to double check if there are any concerns before I more forward with the big search-n-replace needed to purge them. [[User:Kolano|Kolano]] ([[User talk:Kolano|talk]]) 04:24, 10 October 2015 (CEST)
 
  
: I'm fine with this. We don't support 320bit on any platform now. - [[User:MaJoR|MaJoR]] ([[User talk:MaJoR|talk]]) 09:50, 10 October 2015 (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? [[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)
  
=== Global Problems Template ===
+
: 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)
Well, just a reminder: when you add/remove a problem from some Global Problem template, it will not show the recent edit. After you're done, make sure to click "Edit" and then save the page again (without doing any change) one more time to force refresh the templates. It seems that just waiting the wiki server refresh the page isn't working, maybe because the extensive use of variables... [[User:Jhonn|Jhonn]] ([[User talk:Jhonn|talk]])
 
  
We need to get this documented on the Global Problems template docs. [[User:Kolano|Kolano]] ([[User talk:Kolano|talk]]) 08:24, 6 October 2015 (CEST)
+
:: Purged out the unused images. [[User:Kolano|Kolano]] ([[User talk:Kolano|talk]]) 06:52, 13 March 2017 (CET)

Latest revision as of 02:01, 25 October 2019

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)

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

Error with Slash in Search

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

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

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)