Project:General Discussions/Archive

From Dolphin Emulator Wiki
Jump to: navigation, search



Incorrect Ratings

More and more I'm noticing people incorrectly changing the ratings putting a number directly on the list instead of in the ratings pages just undid 2 of the them from the same person.

We need all users to understand not to change the ratings that way or a way to prevent it as its going to get annoying and harder to change. 20:16, 15 August 2010 (UTC)

I think this is generally due to folks being unaware of how to work with the ratings templates. Some suggestions:

  • Revise the ratings template to recognize the numbers an provide info on appropriate corrections.
  • Revise the rating template so ratings link to the appropriate ratings edit page. I'm guessing this would mean generating separate templates per system.

However, we'll likely still see this (and the similar issue of pages using the rating vs ratings template) even then. Unfortunately the best solution may be to just continue to monitor things. The searches below can help with such...

Kolano 20:37, 15 August 2010 (UTC)

I guess theres no scripts or wiki bots that can monitor it automatically for us be good if there was.

I hope people read the ratings links I put on the main page its the best I could do and also It would be a good idea to update each list page so at the top is a big comment about editing ratings they need to scroll past something like.

Put (hash) as I cant put a real one here.


Please don't put ratings in this file use the link below

Link to Wii Ratings list


I added a test example to the Wii page that can be rolled out to all the other lists. 20:56, 15 August 2010 (UTC)

As mentioned earlier wii lists 505'd is now split into 2 lists now and half the ratings for both Wii lists are screwed up now or haven't been added.

Also allot of gamecube games are still inline ratings and not using the template in the game list about 40-50% all games.

Its at a critical stage that about 50% of all ratings for the games over both the Wii and GameCube game lists need to be changed to the template. 15:42, 20 November 2010 (UTC)

Infobox VG thumbnail template

We don't have a template for thumbnails of Infobox VG, so I think that we can use a 300px rendering for covers, a 350px rendering for Wii Channels and a 175px rendering for WiiWare games. Take for example Photo Channel, in Infobox VG you need only to put the rendering in a tag: [[File:Photo_Channel.png|350px]]

Just add the rendering tag after filename. If you are editing a wiki page that use Infobox VG, change the thumbnail to fit in this template. I will edit this in all of my future commits. mbc07 20:25, 20 October 2010 (UTC)


In last days this wiki was attacked by bots that was posting massive spam in the wiki pages. We could implement the ReCaptcha system, if these bots try to create accounts or try to edit wiki pages without an account, they will be permanently blocked (currently doesn't exist any bot that can bypass reCaptcha). mbc07 14:01, 7 November 2010 (UTC)

  • ReCaptcha is already implemented for unregistered users, I noticed it yesterday when I was adding a game without being logged in. Maybe we need a better protection --Trunks 15:16, 7 November 2010 (UTC)
  • The issue appears to be that no captcha is used on user creation requests, enabling the captcha to be avoided if one registered an account. Kolano 16:23, 7 November 2010 (UTC)
  • ReCaptcha has got to be enabled on user creation since this problem is starting to get out of hand. Kolano is doing a great job with marking all the spammers and the pages for deletion, but I'm sure he's getting tired of doing this. ThatLuciano 04:08, 10 November 2010 (UTC)
  • If captcha isn't possible on User requests, in the current case a few string bans (i.e. "n a t o l i . r u") on entries would also likely do the trick.
  • ReCaptcha was already activated for anonymous page edit/creation and user creation! I added wgSpamRegex, strings like n a t o l i . r u are blocked now. Let's see if that helps --WikiAdmin 20:03, 10 November 2010 (UTC)
  • Ho-ray, a day without further spam. Too early to declare victory, but it's at least a good sign :~) Kolano 21:45, 11 November 2010 (UTC)
  • Ah well, it was nice while it lasted. Might want to try adding a few more Spam string bans, though it's unclear how long such will work for. Suggestions: DRUGSTOxxx, CLICK HERE TO BUY Kolano 19:51, 15 November 2010 (UTC)
  • Another suggestion: "http://.*\.ru" which I think would take care of most of the recent spam. I hate to push for such a large ban, though there are likely few .ru domains we'd validly want to link to. My apologies to any Russian counterparts. Kolano 04:42, 16 November 2010 (UTC)
  • Spam is back again, this time with a different template with fewer phrases valid for banning, though odd foreign URLs are there. Kolano 15:14, 24 November 2010 (UTC)
  • Something is wrong since the reCaptcha isn't blocking these bots edition and user creation. We must find another way to block these spammers. mbc07 16:07, 27 January 2011 (CET)

Unresizeable Images

There are at least 2 images on the site that can't be resized with "|300px" in their tags. Not clear what's up. They would be...

FlingSmash‎ Rocky.jpg

Kolano 17:28, 14 November 2010 (UTC)

  • I saw this problem when I uploaded the Sonic Colors cover which I then had to upload it at 300px, oh and I updated yours too ThatLuciano 17:45, 14 November 2010 (UTC)

This problem is caused by the compression method, if you experience this bug again, try to save the same image in PNG format (better quality and doesn't have this issue). mbc07 19:18, 14 November 2010 (UTC)

  • This was a server issue. Mamario already fixed this. mbc07 16:07, 27 January 2011 (CET)
  • Alrighty everyone, I have figured it out, if your image does not resize then you add another little section at the end [[File:Rocky.jpg|300px|Rocky‎]] or in the middle [[File:Rocky.jpg|Rocky‎|300px]] just mess around with it and you'll get the image resized. ThatLuciano 20:14, 14 February 2011 (CET)

Wii List at Critical Length

It appears the Wii game list has it the critical length where the wiki is no longer able to process the number of templates in it. We either need to split it up as we have the GameCube page or determine an alternate way to address the many templates issue. Kolano 17:28, 14 November 2010 (UTC)

I have split into a-m and o-z which will work for now.

Half the titles compatibilities to the template are screwed up in the lists so the lists will need to be edited for that. 15:30, 20 November 2010 (UTC)

Broken Image Sizing

Apparently this issue appeared after site admin updated to Mediawiki 1.6. The current workaround that I've encountered is reuploading the image with resizing problems in PNG format. (I'm not sure if GIF have this bug too) mbc07 22:33, 7 December 2010 (CET)

After tests I confirm that all images format have this issue, I've notified this to Mamario. Now we have to wait for a answer, so some covers that I've recently updated will have this problem, please no revert these files. mbc07 15:53, 10 December 2010 (CET)

  • Mamario fixed this. I've notified too of some images that can't be resized, and he is looking for a solution. mbc07 13:18, 11 December 2010 (CET)
  • Alrighty everyone, I have figured it out, if your image does not resize then you add another little section at the end [[File:Rocky.jpg|300px|Rocky‎]] or in the middle [[File:Rocky.jpg|Rocky‎|300px]] just mess around with it and you'll get the image resized. ThatLuciano 20:14, 14 February 2011 (CET)


Possible fix for GameCube page

I've noticed that Mediawiki 1.6 support more templates, and apparently the GameCube list is working OK, even with all templates included. For help, I've too moved all links and references to the obsolete Ratings to the new RatingsGC, to reduce templates in use by GameCube page. mbc07 22:33, 7 December 2010 (CET)

  • No fix, after mergering htp:// and, the server that is hosting this wiki was changed and accepted a few more templates, but the issue still occur mbc07 16:07, 27 January 2011 (CET)


I know this wiki is very game focused, and doesn't focus on stuff like explaining emulator options. But still, some topics, like DSP-LLE, are mentioned throughout the wiki without any explanation whatsoever. So someone sees the option in the configuration list, tries to use it, error. So they search the wiki, and find nothing. They go to the main dolphin page, nothing in the FAQs or support either. If they do google searches it will lead them to the forum, but even then it's not exactly easy to find. Should this wiki have something to explain certain topics, like DSP-LLE? Even if it was just a page with a link to the forums, it could go a long way to helping users figure out how it works. Obviously I am not suggesting we explain every single option available for configuration; that would take far too much effort to do as it changes all the time, and dolphin itself does a great at explaining things usually. But it might be nice to have something on the wiki for those that need it, just to help push them in the right direction. MayImilae 20:11, 08 June 2011 (UTC)

Compatibility/Testing Validation

We seem to have an influx of users who don't pay attention to listed issues when providing test entries or compatibility ratings. mbc07 and I have been rolling back/updating most of these as they occur, but it's becoming a bit annoying. We've tended to leave test entries alone, but there are now a number of "no known glitches" test entries for games that clearly still have issues. Do folks have any suggestions regarding ways to improve the handling of such? Kolano 04:48, 30 October 2011 (CET)


Transition to New VGRelease Template

"Looking at the Template, it fixes alot of old problems with vgrelease, like, it gets rid of the automatic reordering (which requires some ugly formatting to dance around), it lets you specify any region without it being spelled out in the template, and gives you more control over formatting. I don't do templates, but it may be worth considering to adding it here, either was vgrelease new or incorporating into our vgrelease somehow." MayImilae 21:54, 17 July 2012 (CEST)

Unfortunately the template isn't compatible with the parameter format of the current VGRelease. This means that each page using the VGRelease template will need to be updated. Listing it here till we get up the effort.Kolano 05:37, 18 July 2012 (CEST)

Moved to a new server

We've just moved to a new server, and the new wiki administrators (Parlane and No cluez) are actually Dolphin developers, so any problem what we found should be quickly solved now if compared when Mamario was the only admin. Now, we have a better spam blocker powered by reCaptcha, but some pages needs to be updated since some pages moved to other locations (in fact, all pages of "Dolphin Emulator Wiki" namespace was moved to "Project" namespace). Also, any link to the old server ( should be changed to the new site ( | mbc07 (talk)

All links to the old server have been fixed. The only place where "" is mentioned, on the entire wiki, is on this page. - MayImilae (talk) 01:01, 3 November 2012 (CET)
...Or not. Crap. It's going to be hard to find them with this crappy search function. It showed it was done! Oh well. I'll keep at it. - MayImilae (talk) 09:45, 3 November 2012 (CET)
Ok, I think I got them all. I can't find any more with any search results. Phew - MayImilae (talk) 06:42, 6 November 2012 (CET)

Forum Integration

As has been announced, the plan is to use the wiki for game pages and tutorials on the forum. Win for everyone. I talked about it with the devs, and it should be pretty seamless; the wiki in form and methodology will not change, they'll just have easier access to our world for popular games. But they did have a couple of little things they wanted. First, is more screenshots. No complaints there, and that can easily be added with a gallery. The second is collapsible and collapsed-by-default testing entries. Alot of testing sections run really long on some pages (just go to a zelda game...). Delroth believes he can make it collapse on just the forums (I have no idea how that would work), but uh, do we want it to just be there? I mean, they are REALLY long on alot of pages. Collapsing the testing entries would make for alot cleaner pages... The last thing is they want links to any custom texture packs that are available. Should be simple enough, do it like the patches on Xenoblade Chronicles.

So, here's what we need to figure out. We need to get a screenshot standard set up. The only spot on the wiki with screenshots I know of is Resident Evil, and it's really old. Make them 300px perhaps? We also need to figure out how to collapse testing entries, and if we want to collapse it here and there, or just there (if that's possible). And we need to agree on patches and texture stuff, but I think it's pretty easy to say just go with the Xenoblade style. Oh, and once we get things settled, someone should probably write up a wiki 101 for the forum. Probably me, since I've been doing a lot of the go between, and suggested it... Well, what do you guys think on all this? Delroth said he's going to work on it tomorrow, this is going up FAST, so let's try to jump on it as best as we can. - MayImilae (talk) 14:06, 6 November 2012 (CET)

This is indeed a great change, which will prevent double and outdated work. Thanks for suggesting it MayImilae! I agree with some of the testing sections being too long. A simple way to reduce them is to delete the ancient testing data and useless testing without proper descriptions. You are referring to the thumbnails for the screenshots right? The Resident Evil ones look good, but there's a bit too much padding for my taste between the screenshot and the outer-box. I'll help with the wiki 101 for the forum if someone makes a start. :P As for the high resolution texturespacks. I think we should create a section for them under each game which has packs available. It'll be more organized that way. - Garteal (talk) 14:14, 6 November 2012 (CET)

About the test entries, they're built based on a predefined table (from the template)... Before the server change, I've implemented show/hide functionality to the navigation templates (Template:Navigation). The navigation templates are based on tables too, so, implementing this functionality to the test entries shouldn't be hard... Adding this to the To Do - mbc07 (talk)
Ta Daa, all testing entries of the wiki now are collapsible and, by default, load hidden when someone access the page. The only thing changed was the table header and a new line was added because we can't choose in which column the show/hide "button" appear (it'll be always the first). Looked better and more suggestive for me having a row named "Test entries" (or whatever you guys want to) with the button than having the button on the side of Revision column collapsing all other columns together... Any suggestion or objection? Something you guys think that need to be changed? - mbc07 (talk)
I have not much to add since it's perfect in my eyes. Very clean solution aswell. Nice job mbc07! -Garteal (talk) 21:38, 6 November 2012 (CET)

I've testing some concepts and now I have the following suggestions: first, I think we should completely remove the column "Tester" from the test entries. I never saw utility for this column, and since we're going to have the wiki pages linked to the forum, this would only cause confusion, like forum members adding their nicks to the tester column and we being with a lot of red links pointing to these users that doesn't exist on the wiki.
Second, since some pages have only Videos and others have only Screenshots, I think we should merge the two sections in only one section named "Media Gallery, using the standard 300px size for thumbnails, etc. Actually, I commited an example in the sandbox of Resident Evil, the screenshots have a little big margin and aren't aligned with the videos, but in case we use this concept, I would make a template to simplify the usage of the screenshots (something like Template:YouTube, requiring only file name and caption) and add the proper CSS styles to make videos and screenshots aligned. What do you guys think about these suggestions? - mbc07 (talk)

Whoa, that was fast mbc07. Sweet! I really like the testing work. Though it might be nice if it remained the whole length of the page when collapsed, for consistency, but that's just nitpicking. I disagree with you on the tester column. It goes to an automatically generated contribs page here on the wiki, not to a forum link or anything else. That's why there aren't any red links right now. I think it's nice, cause it shows who made the edit, and what else that person did. I like it. As for your ideas for the media gallery, I'm all for it. Most pages only have a few videos anyway. But yea, it will need to have the alignment fixed and stuff for that. Today is a little busy, with voting and all, but I'll jump into the work as soon as I can. - MayImilae (talk) 23:30, 6 November 2012 (CET)

In this case, let's leave the tester column as it is now. After the forum integration is complete it would be nice to provide a comment somewhere warning the visitors to only add her/his nickname on the tester column if he/she have a wiki account corresponding to this nickname, so, we avoid the red links. Just to be sure: when you say "it might be nice if it remained the whole length of the page when collapsed" you are referring to the table width right? In this case, a simple CSS style should do the trick... I'll (try to) fix this and also mess around with the alignment and position between videos and screenshots when I get more free time, so we can finish a standard for the upcoming media gallery - mbc07 (talk)
As delroth said, too many videos. I ran into the hangups, but I thought it was because of dialup. So, what do you prefer? Purge all but 3 videos? Or have 3 videos, screenshots, then links to more videos? I'm a little on the fence on this one. If we have more video thinks, a joined media gallery is probably a bad idea, and better to have screenshots then videos, I'd think. Hmm... - MayImilae (talk) 01:46, 7 November 2012 (CET)
I like the media gallery suggestion mbc07. I do think there has to be a limit though. Also pondering about what MayImilae suggested. Perhaps we should limit it to screenshots only? Or if we also want videos, there should be a maximum limit of 3 of them or so. What will we do to the rest? Delete them? Or link them somewhere below the embedded? --Garteal (talk) 13:13, 7 November 2012 (CET)

Standards for Videos and Screenshots

Alright guys, let's get the whole video and screenshot thing settled. I've added some screenshots and created a Brawl Sandbox, and we can use this to finalize how we want to do it. The idea is that it has no cap for screenshots, but they are 200px (we can always add a cap), and presented in a gallery. Embedded videos are 300px and use the youtube template, and are capped to 3 videos per page, with links to remaining videos. (I have no idea how we'll pick which videos are shown and which aren't, but, yea. HD receives priority?) Gameplay videos are presented after screenshots because the links disrupt the flow of the page, having it go from thumbnails to thumbnails makes a cleaner look. And last but not least, screenshots have categories. Wii screenshots, GameCube screenshots, etc etc. So guys, do you like how it's done there? Any changed you'd like? - MayImilae (talk) 12:54, 8 November 2012 (CET)

If we don't have a cap, it will increase the loading time of the page depending on the number of screenshots and their quality(lossless PNGs, etc). Imagine if there's like 10 3MB shots in there. In order to address that, we either have to limit the screenshots to JPG only to reduce the filesizes and loading times, or have a reasonable cap. I like the 200px size for screenshots. The only thing that remains is the padding of it, which iirc, mbc07 was going to address. As for the videos, the three that should be embedded have to be recorded without any emulator glitches (if possible) and has to be high quality videos (if possible). We'll have one video for each type, eg: one video showing the gameplay, one the intro, one shows the battles. 300px seems reasonable to me. And yes, I like the cleaner approach as well, so good job on that MayImilae. As for the screenshots category, are they meant to show a giant gallery of every games' screenshots? - Garteal (talk) 13:16, 8 November 2012 (CET)
For the record, screenshot thumbnails are generated automatically by the wiki, and they are extremely small. Dialup can load that sandbox in no time, trust me. In fact, I just downloaded one just to check. 4KB. Yea, that'll bring your browser to a crawl :P. Anyway, we can have any as many screenshots as we want on the page, without worrying about load times. The only reason for a cap on the videos is because they were causing a stall as browsers loaded them, due to the crappiness of the flash plugin. As for the one video of each type thing, I don't think that's a good idea, simply because we only have so many videos to pick from. I think we should just pick the best ones, taking into account HD, any glitches present, and overall quality of it. - MayImilae (talk) 13:46, 8 November 2012 (CET)
Okay, I didn't know the wiki generated the thumbs, so that's good news. Alright then we'll see how it plays out without the cap. And yes, we don't have videos for every game, but I hope people will post their videos here now that the forum threads also link to the wiki. If there are enough videos then what I said could be applied, if you all agree with it ofcourse. I just think that it'll be more interesting to have different parts of the game shown than just the same gameplay style. Generally we'll want the best possible videos to show off Dolphin yes. Glad we agree. :P - Garteal (talk) 13:53, 8 November 2012 (CET)
OK, here are my thoughts:
  • Number of items:
    • As already mentioned, the in wiki image resize should handle screenshots fairly smoothly, unless someone goes really crazy.
    • It would be preferable if an ad hoc number of things could be used for either, though I understand the limitations of starting up many copies of the Flash player. The ideal here might be to generate a fancier embedvideo go between template that could:
      • Accept an arbitrary list of videos (preferably inclusive of those outside of YouTube).
      • Select a random position in the list (1 to length-3) if longer than 3 elements.
      • Display 3 videos from that position
      • Perhaps if we really wanted to get fancy actively rotate through the full list of videos
...the main goal to enable long video lists without requiring significant admin overhead to review/prune them.
  • Listing videos post embedded videos: Not sure how much I like this, since it will mean going through some process to review and select how to handle each new video >3.
  • Pruning/Selection Rules (Though I don't like them):
    • I don't think the videos should necessarily be "recorded without any emulator glitches", unless we intend to separate bug related videos into the problems section. Some games simply can't be played without glitches, and I'd still like to capture video of them. Also some glitches can be difficult to describe/communicate outside of videos. Perhaps this is just a matter of where glitchy videos are located on the page (Gameplay Videos vs Problems).
    • HD/Higher resolution should be preferred
    • Non-camera sources should be preferred (i.e. there are a number of videos recorded with handheld cameras that tend to be of low quality compared to in machine captures)
    • Outside of cases of compatibility losses (i.e. 3.0-113 breaks XXX, so we keep video from 3.0-112), videos of more recent releases should be preferred.
      • This one I'm cautious of, mainly since I feel the older videos do a better job of capturing past compatibility than test entries do. Again probably just a difference of where video links are included (i.e. Testing vs Gameplay Videos)
    • Videos with only game audio preferred. Various videos have mic'd in audio usually irrelevant narration or simply loud environments, which should be avoided if possible.
    • Video is embeddable. Apparently some videos can be configured to not be embeddable, refer second video on Super Mario Galaxy 2.
  • Unrelated Side Issue: In the current layout for embedded videos when videos wrap they sometimes position oddly. This is due to using floats to position them and some boxes being of different height. The frame box needs to have a consistent height for clean wrapping with floats.
Kolano (talk) 20:10, 8 November 2012 (CET)
I like alot of these ideas with the templates. A way to automatically handle the 3 videos selected for embedding would be awesome. I'm not sure about the image template though. I know it's a work in progress, but it's currently not easier to use than a gallery, which is bad. It also is 300px only, which makes it somewhat inflexible. It would work well for bug images, but if screenshots are 200px and bug images are 300px, it couldn't do both. And I still think 200px might be better for screenshots so we can have more... I know everything is a work in progress, just you know, saying my thoughts. - MayImilae (talk) 22:53, 8 November 2012 (CET)
Well, I already fixed the alignment issue on YouTube template (this means that if you embed videos using youtube template and images thumbnails of the same size, they'll be aligned properly now). I'm still trying to develop a template to randomly select 3 videos (whenever a visitor access the page) and put the rest of the videos (if exist) as links. I'm trying to make it without using expensive parser functions, but implementing this aren't so easy. In the last case, we can embed only one Video thumbnail but instead of using a single video ID we use the ID of a playlist containing all videos of that game, or, search in MediaWiki for a Video Gallery extension (that we may ask for some site admin install) or some extension that make possible of doing a template that works like the Kolano suggestion (for me, the best until now). About the WIP Image Template, I can add an parameter for setting thumbnail type (like bug, image gallery, screenshot, etc.) and then we hardcode the thumbnail size directly in the template (like XXX px for bug, YYY px for screenshots, etc.). The most important part is to keep using small templates like YouTube and the WIP Image to make easier changing thumbnails size, position, etc in the future. For example, if all testing entries from the wiki has been hardcoded in every game page instead of being included through a template, making them collapsible would need editing every single game page (like we'll need to do when the media gallery standard is set). Since we used a template, a simple change in the template source made all game pages have collapsible test entries - mbc07 (talk)

Uh, guys... wiki activity has gone through the roof thanks to the forum integration, and all the youtube videos have been changed over (we'll have to clean some stuff up once things are all settled), on and on and on. But uh, we still don't have things set on how to handle everything! Do we go with a media gallery or gameplay screenshots/gameplay videos, do we have a limit on youtube videos, how is that handled? I don't mean to be a nag, and I know there is work to do first, as we need to investigate the randomizing and stuff, but still, stuff is happening, we need to get on this. Let's just keep moving forward. - MayImilae (talk) 04:45, 11 November 2012 (CET)

The media gallery will have both videos and screenshots right? If so, that would be a bit cleaner. Having only one category, with three videos on top, followed by countless screenshots. As for the limit, I think we've all mostly agreed to having 3 as a limit. I agree, the randomizing is a good idea, which isn't hard to implement, so we'll have to wait for mbc07 in that regard. In a nutshell: 3 videos(embedded) and unlimited screenshots, right? -Garteal (talk) 12:11, 11 November 2012 (CET)

Well, what about the additional videos? Links? Links would kinda ruin a media gallery. Plus screenshots and videos would have to be the same size for a gallery, and I was talking about using 200px. See, we have stuff to discuss. Oh, and don't forget Kolano :P. - MayImilae (talk) 12:26, 11 November 2012 (CET)
Ofcourse. We all have to be on one line for things to happen, so we'll discuss until that is settled. As for what I meant, I thought it was better to create a mockup then try to explain it. This is what I meant for the media gallery, or atleast, something close to that. So they don't necessarily have to be the same size. As for the additional video links, if we have Javascript/PHP support, that can be easily settled. Though we might have to create a location where people could contribute their videos to. - Garteal (talk) 12:48, 11 November 2012 (CET)

Standard suggestion: the unified Media Gallery

Ok, I've just finished my work with the video gallery template and I'm trying now to set the final standard for the Media Gallery. My suggestion:

  • Every page have a section named "Media Gallery"
  • In this section, by using the video gallery template, 3 videos will be randomly selected and displayed as the first three thumbnails (if the game page have less than 4 videos, the videos should be included with the normal YouTube template, as using the video gallery template will have no utility with less than 4 videos)
  • After the first 3 videos thumbnails, we'll have countless screenshots included through the Image template
  • By using these templates, we make sure that all thumbnails (both images and videos) have the fixed size of 300px.
  • If the game page have more than 3 videos (and use the video gallery template), after the Media Gallery section we'll have another section named "More Videos" with links for the another videos.
  • At least in my desktop, running at 1440x900 this isn't an issue, but if necessary, add a <div style="clear:left"></div> after the first 3 videos thumbnails to fix any issue we could have with the floating elements in computers with higher desktop resolutions...

Take a look at Template:VideoGallery/test, is the SSBB page using the standard I'm suggesting. It's already using the random thumbnails feature, but if you guys want to see another example in how the video gallery template works, take a look at Xenoblade Chronicles. Well, what do you guys think about this standard? I think we can already start using it. - mbc07 (talk)

Well, personally, I still prefer smaller thumbnails for screenshots. The goal is to have a fair amount of them, and we could end up with quite a few. Plus the isolation between screenshots and videos is very clean and organized. And well, I just think it looks nice. So, in my opinion, I'd rather we go with something other than the media gallery. As such, I'll suggest an alternative like what I proposed before: 200px thumbnails for screenshots in a gameplay screenshots section, and then the youtube template with 3 ~300px videos and then links in a gameplay screenshots section. Let's see what everyone thinks between the two of them. And no matter which standard we go with, you did awesome work mbc07. - MayImilae (talk) 01:46, 14 November 2012 (CET)

Ok, my only request is to ALWAYS use the image template or one of the two video templates (using video gallery template only if the page have more than 3 videos), no matter which standard we go with. The thumbnail size can easily edited, directly in the template, by replacing the 300px tag with the desired size and changing the 275px tag with the desired size minus 25px (for example, to make the template generate 200px thumbnails, we should have 200px in the first tag and 175px in the second). This request is to make quicker fixes in future (like what was done with testing section) and because using the <gallery></gallery> tags or calling embedvideo directly gave me countless issues with floating elements and made the thumbnails size be "fixed" with a smaller size, even when specifying a higher width... - mbc07 (talk)

I'm in agreement that the screenshots/video thumbnails should vary in size to more easily distinguish them. Related to such I think separate Gameplay Videos/Gameplay Screenshots sections make sense. I'm still unclear we will ever have that many screenshots though, since the few for Resident Evil were all we ever got previously. Having the VideoGallery template is very nice though. Thanks so much for working it out John. It resolves my primary prior concern of not wanting to have to take time picking and choosing videos (though we probably still need to generate some rules to restrict videos, such as ones that point to pirated content in their descriptions/initial comments).Kolano (talk) 02:23, 14 November 2012 (CET)

There are TONS of screenshots on the screenshots forum thread. I have dialup, so I can't do it, but someone could very easily port those over. - MayImilae (talk) 03:06, 14 November 2012 (CET)

Well, I guess we have a consensus then? Separated Gameplay Screenshots and Gameplay Videos, with 200px for screenshots using the image template and 300px for videos using the video template? Any comments on specifics of that? Hmm, maybe we should make a new template just for screenshots, for the 200px and to remove descriptions. That way we could keep the image template as an optional choice for bug images and the like? MayImilae (talk) 08:24, 17 November 2012 (CET)

Ok, this is the standard. We can start commiting this standard in the game pages. I'll make the Template:Image more configurable when I have free time, specifically, to don't include the caption (screenshot only mode) via a template parameter... For now, just use the template without any tag in the second parameter, when I implement this, the caption space will be automatically wiped out) - mbc07 (talk)
Glad you are adding a way to remove the caption space, I tried to get it sorted but failed, badly. Hmm. One little problem: almost all of the videos on the wiki have been changed over to the youtube template thanks to Kolano. Should we just use that, or go with the video template? - MayImilae (talk) 09:36, 18 November 2012 (CET)
We should use the video gallery only if the game page have more than 3 videos... The rest of the pages, with 3 videos or less, should just use the YouTube template... I think there is no way of checking this instead of manually checking every game page to see which page have more than 3 vidoes, and then, updating it to the video gallery template =/ mbc07 (talk)
*tries it. Oh... Set it to just one video and it generates 3 copies of the video. Crap. That complicates the standard a bit... - MayImilae (talk) 02:17, 19 November 2012 (CET)

Media Gallery standard: the final consensus

Well, about 1 month of discussion and a lot of working in various templates. Here is the final consensus:

  • Every game page will have 2 sections: Gameplay Screenshots and Gameplay Videos (in this order)
  • In the gameplay screenshots section we'll have countless screenshots, all of them MUST BE embedded using the image template, with no caption, at 200px size.
  • In the gameplay videos section we'll have countless videos, all of them MUST BE embedded using the video gallery template which will automatically choose 3 random videos to embed as 300px thumbnails and add the rest of the videos as links, below the 3 thumbnails, by calling {{#var:videolinks}}.
  • The gameplay videos section should ALWAYS use the video gallery template, even if the page have less than 4 videos (the template automatically handle these cases now)
  • EXTRA: for bug images and things like that, we should use the image template with a caption. Then, the thumbnail will be set as 300px, with the caption in one line (getting automatically truncated, if necessary). I'm setting this thumbnail as 300px to distinguish them form the screenshots and gameplay videos and because a lot of pages already uses the 300px size when an image is embedded with a specific problem. Also, having 200px screenshots for the bug images make the caption too small.

That's it. I already fixed everything in the templates and updated Template:VideoGallery/test to fit in this standard, I think this should be the standard template, so we can start commiting this damn thing in all pages (c'mon guys, this discussions is taking too many time!) But since this is a community driven project, I'll ask again: what do you guys think about this standard? Any objection? - mbc07 (talk)

Works for me. It's very easy to use, I like it. I have one tiny nitpick though: is it necessary to have the "cap" separated in the video template? Stuff like |vid1=R9u_BJXRyuI|cap1=super smash bros brawl in 3d dolphin emulator could very easily be |vid1=R9u_BJXRyuI|super smash bros brawl in 3d dolphin emulator instead, unless there is something in the template to prevent it of course. It's just a little nitpick. Awesome work on the templates mbc07. - MayImilae (talk) 23:22, 19 November 2012 (CET)
Well, the way how templates work doesn't allow it. I can get parameters without any prefix by using {{{1}}}, {{{2}}}, etc, but since the template randomly select one of the N videos that have been included, I cant "find" the number that correspond to the capN parameter of the selected video (because this number vary depending in which entry the template randomly selected). To avoid these kind of issues, we need to declare the parameters, allowing to get the capN by using {{{capN}}} regardless of what location it's defined, so, from my knowledge, there is no way of implementing this... - mbc07 (talk)
Gotcha. It's fine, it's very easy to use now. - MayImilae (talk) 02:59, 20 November 2012 (CET)
Unless delroth is able to filter the rest of the screenshots out, we might have to limit the screenshots, since it'll really mess up the game threads in the forums. As for the video section, are you able to hide the rest of the links, leaving only the embedded videos visible? That would make things much cleaner, and will let you put the video section above the screenshot section, since it'll be a hassle to scroll down to the video section if the screenshot section becomes huge. Last, but certainly not least, I would like to say you've done an amazing job with the video template mbc07. ─ Garteal (talk) 16:13, 20 November 2012 (CET)
I've updated the Template:VideoGallery/test with you suggestion Garteal. Looks good to me, because it already prevent any future issues with the Gallery standard if we have too many videos or too many screenshots. So, I'll commit this to Project:Wiki Conventions and then, we can start using this as the final standard for the media gallery... - mbc07 (talk)
Whoa whoa, why are the screenshots below the videos? *looks* Oh... Well... I disagree with this. The screenshots are smaller specifically to address this problem. And as Kolano said early, we probably won't have tons of them anyway. And this solution creates a bigger problem than it solves; it creates a mental disconnect. Having the video links so far away from the video thumbnails is simply making the links disappear, camouflaged in a sea of text below it. I don't think the composition works like this. The only way to avoid that disconnect is to keep the the videos all together. Honestly, if we are going to worry about this, then the best solution for this would be to just go ahead and set up a proper gallery like the videogallery and get it over with. - MayImilae (talk) 07:19, 21 November 2012 (CET)
I agree with Major. Separating the video links into a separate section seems silly, and the extra title just eats up more page space. Kolano (talk) 07:48, 21 November 2012 (CET)
The order of the sections is subjective. I just explained what my thoughts were on it. The screenshots being smaller won't solve anything if a boatload of screenshots get added eventually. Just pick whichever gets the most votes. Personally I'm for either. The More Videos section can be removed if the links in the Gameplay Videos are hidden. (Why are they visible again btw?) I'm glad we're finally getting to a final decision. :) ─ Garteal (talk) 11:57, 21 November 2012 (CET)
The overflow videos are shown as links so the full set of videos are available for view. Without the links one may need to refresh the page many times before a newly added video would be shown. Only 3 (at random) use the embed which takes up more space. If you are really concerned about the space consumed by videos we'll need to discuss rules to trim the video lists, a topic I was generally hoping to avoid. Kolano (talk) 19:56, 21 November 2012 (CET)
One other issue with the VideoGallery template. As far as I can tell it only supports YouTube videos, there are video links from a variety of other video sites on the wiki, so we need to decide how to handle them if we transition to using the VideoGallery template.Kolano (talk) 07:51, 22 November 2012 (CET)
Wich other services? The template itself already support other video services (just add srvN=<name of the service> before video ID. In the first time, I need to create a copy of youtube template modified for other services, but this can be done in no time... Well, to prevent any future issue, I'll add the initial template for all services, ok? mbc07 (talk)
Ok, almost all services supported by EmbedVideo plugin can be used with Template:VideoGallery now. Edutopia service wasn't added because this site simply embed videos from YouTube. Revver and TeacherTube weren't added because these services doesn't exist anymore. FunnyOrDie and Vimeo were added but EmbedVideo plugin is outdated, generating broken thumbnails (these 2 services works only in "link mode"). Sevenload wasn't added because this site doesn't work here where I live (Brazil), so I couldn't access the site to get a sample video link and add support... mbc07 (talk)
Thanks mbc07, now we just need to update the VideoGallery docs to indicate the services availible. I had been noting pages that used alternate video services, but I'm away from home for Thanksgiving so it may be a while before I'd get to accounting for them to use embeds Kolano (talk) 18:48, 22 November 2012 (CET)

Suspicious Users

I suspect a spammer is trying to build up some user accounts. These users have odd names that seem randomly generated, and were created without performing any edits:

  • Racn42pysi
  • Jan5318bwi
  • WoodrowWcx
  • Boscaposi
  • Gaye6z37ge
  • Err225deki
  • Con67sy5ba
  • Jan3jvudju
  • Sig96yx8gi
  • Joh4hvfuke
  • Fra5befxli
  • DarleneLfy
  • Yacht member1
  • Simsmagic
  • Mer8qq9ysh
  • Wal6291kst
  • Civ1994
  • Cprs (This ones a bit different than the others, and may be unrelated)
  • Teoberpriller98
  • Seloy93
  • Cukali36
  • Caphung49
  • Hbryon39
  • Filorraine31
  • Tplautz19
  • Shstoermer22
  • Mtamie82
  • Mr.Shibby (This ones a bit different than the others, and may be unrelated)
  • TopFunny525
  • Tohemmings32
  • Rkisamore30
  • Tahuna16
  • Qusills78
  • BrandenTd (This ones a bit different than the others, and may be unrelated)
  • Xiao21
  • Sowestrum37
  • Duflorentino31

Which covers the suspicious ones over the last 100 user registrations, though there are many more of these. I'm reluctant to perform preemptive blocks, but have a feeling we'll still be cleaning up after spammers for some time if we don't.Kolano (talk) 08:56, 24 November 2012 (CET)

It is probably someone failing to use the SEO spambot tools properly, and not a nefarious plot for later. After all, I've never seen a spambot come back later, they have always always joined then immediately spammed. Here, you should read this article, it gives a ton of information on the kind of spam we get here at the wiki. - MayImilae (talk) 12:04, 4 December 2012 (CET)

Solved by the change to question based captchas. Fixed by Delroth in late December of 2012. No new suspicious users or spammers are being made, but the old ones remain.

Infobox Automation

Uh, your changes are breaking a few things. I'll just show you. Any time I make an edit, I get stuff like this: Metroid Prime: Trilogy. The stuff in the genre area is added as categories, except that area doesn't follow the category conventions. The only solution is to remove the existing categories and modify the genres area to fit the conventions. Of course, the vast majority of game articles' genre areas don't follow those category conventions... - MayImilae (talk) 05:54, 1 December 2012 (CET)

I'm working through correcting the genres now. Kolano (talk) 05:55, 1 December 2012 (CET)

Cleaned up all the genres responsible for red-link categories, and performed some other general clean-up of the genres. Genre stuff should now be a bit better, but there's a bunch of remaining tasks...

  • Merge Platform and Platform genres
  • Ensure all sports genres are labeled as such, similar genre grouping edits needed elsewhere as well (Role-playing, Shooter, etc.)
  • Purge in page genre categories / transfer to infobox genres section
  • Better review available genres for each game an populate as appropriate

Kolano (talk) 08:05, 1 December 2012 (CET)

Wait wait wait. Why are you removing ALL game categories? That is extremely limiting. Putting them all in the infobox means you either can't do additional categories for connectivity, or you get messy results like, well, "First-person action-adventure, First-person shooter, Action-adventure". Long enough? What about Wii Sports? "Sports, Party, Tennis, Boxing, Bowling, Baseball" And you don't want me to list Wii Sports + Wii Sports Resort.

Ok, let me just be frank, I didn't like this idea in the first place. Automated infobox categories is limiting for genre blending titles such as this. But it does have some value, as everyone forgets those categories but us, so I see why you did it. So, I think it can work if we're flexible. So like, have "First-person action-adventure" in the infobox, and additional categories to help with navigation and inter-connectivity be nice and neatly tucked away on the bottom, where they belong.

Oh, and sorry about that Prime 2 edit. I thought I screwed up, and it didn't occur to me till later that you made changes behind me. Maybe it's meaningless, but I think it's important to handle stuff like this without edit wars, so I try to avoid stuff like that. - MayImilae (talk) 08:53, 1 December 2012 (CET)

You're right in my thinking regarding the automation, most pages were very inconsistent between their genre/modes/categories listings. The automation makes it easier to see and maintain our current genre lists and keep things consistent. I'd generally prefer to avoid the duplication of genre information around a games page, so in most cases I'll prefer to just have a long genre's list in the infobox. Having it mixed around the page is confusing the novice editors, who may not notice the multiple edit locations. Even Wii Sports + Wii Sports Resort, the longest current genre list, only ends up taking 5 lines. It's controllers section is 4 lines, so it's not without precedence, and such only occurs on a few pages (the Deca Sports titles are another problematic case).

Also, generally, I'm not sure I'm a fan of the the german-like mashed together genres vs just listing each of the multiple genres that are mashed. In many cases, it seems to be a marketing ploy to some degree, but as said previously including them generally doesn't terribly effect anything anyway (i.e. an additional line of genre listing is not a big deal). Another option here may be to just hide the "genre" line in the infobox, since the info will be represented as categories now anyway. Alternately I can likely work out something to reduce the font size if more than a certain limit of genres is listed.

Was hoping to work on series categories next, and perhaps dev/publisher ones. Please let me know if you want me to hold up on such prior to some further conversation/agreement? Kolano (talk) 09:20, 1 December 2012 (CET)

I think you have a good idea overall. This could really help expand inter-connectivity and give us a more consistant setup. That's awesome. That being said... I'm an artist, so the flow and structure of the page is very important to me. Still, "Sports, Boxing, Bowling, Golf, Baseball, Tennis, Swordplay, Wakeboarding, Frisbee, Archery, Basketball, Table Tennis, Golf, Bowling, Canoeing/Kayaking, Cycling" is an absolute disaster. And I know I know, the input list is long, but it's just that game, and there is no alternative for it. With genres, there is.

I really like having an overflow of sorts for odd pages like this. Sort of how wikipedia handles it, and closer to our original. Whenever someone adds a new game article (other than us regulars), they would just put in what wikipedia has, or nothing at all. I don't think that making it consistent will have any impact on that. And it would give us a much better look to the page. So, for Wii Sports Resort, just have the primary category (Sports) and then fill in all the little blanks we want for interconnectivity. That is much much nicer. - MayImilae (talk) 10:31, 1 December 2012 (CET)

I fear we loose the advantages of the automation and end up with inconsistent pages if we operate in a mixed mode. This only seems to be a real issue with ~10 pages, which also seems far too few out of the 1000+ total to be much put off by. Hopefully we can get some input from others. Kolano (talk) 11:18, 1 December 2012 (CET)

You know... if we put the platforms back into the infobox, we could get rid of all category additions to the bottom of the page. It would simplify game page creation, especially when pasting from wikipedia. Not to mention help newbies, since it's one less thing to worry about. We could just tell them to delete the non-Nintendo platforms, instead of telling them how to make categories, where to put them, and what categories to use. - MayImilae (talk) 03:31, 7 January 2013 (CET)

Compatibility List PAGESINCAT

Virtual Console says "This lists 24 titles released on Virtual Console for the Nintendo Wii video game system". ...there is way more than 24 games in that list. It is, of course, because of the pages in category function. Only 24 virtual console pages have been made, but there are hundreds available which exist on the list as empties. This quirk is present on almost all of the compatibility lists right now, as there are a ton of empties all over this wiki thanks to scripts which added games to the list to keep it accurate and encourage people to add pages. I support that concept: filling them in slowly over time sure beats trying to do it all at once. The pages in category issue could always be solved by making tons of pages fill empties, but uh...

1. It's a lot of work, even if the pages are blank except for the categories

2. Newbies don't know how to approach blank pages, which means we either do more work now (no blank pages) or later (fixing problems from blank pages)

3. by the time the wiki's list is updated, that's thousands of empties to fill, so yea, alot of work.

Really, we'd need scripts to do this effectively, and that means figuring out the scripting API, getting delroth's and parlane's help, and alllll that. Without scripts, that means making thousands of pages manually, and that would take obscene amounts of time, even if they are blanks (something I think is quite dumb). So yea, making that PAGESINCAT thing display the right number is a absolute gigantic mess, so I say let's just avoid the problem entirely and remove the PAGESINCAT bit from all the pages. I don't think anyone is going to object to me saving us obscene amounts of work, so I'm going to just remove it. But in case anyone has alternatives, and because the tiny edit summary blank couldn't fit the explanation, I'm putting it here. - MayImilae (talk) 12:00, 4 December 2012 (CET)


TOC Issues

While working on the Dolphin Manual I've realized that it's going to have content box that will GIGANTIC. The biggest content box on the wiki ever. It will be even worse than the FAQ. I need a way to deal with this. Looking around, I found this: wikipedia:Template:TOC limit on wikipedia. It looks extremely simple, with very short code, and it would help. Honestly I'd rather have a put the TOC into the sidebar, like the mainsite's faq, but since we can't do that... this will do. Do you guys have any better ideas, or should I go on ahead and try this template? (and inevitably break something and need mbc07 to bail me out :P) - MayImilae (talk) 06:47, 18 April 2013 (CEST)

Well, this fix the issues with the big TOC, so, you should try... The template is very simple, the only possible issue would be with our custom CSS schemes, but it should work without any problem - mbc07 (talk)
Ok, implemented it. Luckily, the template didn't cause issues with our custom CSS schemes (YAY!) mbc07 (talk)
Thanks. See, now I'm so scared of templates that the time I asked you to do it, I actually could have done it *facepalm*. - MayImilae (talk) 22:04, 23 April 2013 (CEST)
Don't be scared guy, found a template, implement it. Caused issues or broke things? Don't worry, sooner or later somebody will help fixing it, after all, it's a community! It's the best way of learning, when the wiki was born (mid-2010, in Mamario's server), I spent a looong time breaking things when implementing templates, and almost all times I needed Kolano, Keller999 and ThatLuciano to fix up the mess. You'll see, soon you'll be creating/implementing very complex templates without any issues =D - mbc07 (talk)

Heads up: website guides now hosted on the wiki

Just so you know, MayImilae is probably aware of it since we already talked about it on IRC: the guides displayed on are now hosted on the Dolphin Wiki. I purposely did not make it too obvious on the website (no link to the wiki page, no edit link, etc.) to avoid attracting vandals.

If you want me to add any other good quality guide to the website, ping me by email (best way to make sure I notice your ping... I tend to miss stuff happening on the wiki).

Thanks for these guides, and try to keep them up to date :) delroth (talk) 19:36, 9 April 2013 (CEST)

Really cool, but the main site is multilingual and the wiki is English only... How we'll address that? Also, maybe we can remove the wiki's FAQ now since the FAQ of the main site is multilingual and the one in the wiki is just a duplicate, and english only... What do you guys think? mbc07 (talk)
Not sure how to handle guides translations - I think in the first place we should try to get good quality english guides, then think about translating them. My current idea is to export the wiki pages as separate Transifex projects, and have a bot syncing the Transifex translations with wiki pages named like "Performance guide (fr)" or "Performance guide (de)". I don't really want to work on it atm, if I haven't done anything about it in a month just ping me. delroth (talk) 23:34, 9 April 2013 (CEST)
Don't worry. However, my only suggestion here is using subpages instead of separate ones, like what we do with the Navigation template (eg. "Performance guide/en", "Performance guide/de", "Performance guide/fr") mbc07 (talk)
Delroth just gave me access to the main site's FAQ. Well... there wasn't a lot of activity on the wiki FAQ anyway, so hopefully that will help keep everything up to date. So I guess now it's time to remove our FAQ and link to the main site's FAQ. Anyone opposed? - MayImilae (talk) 00:56, 10 April 2013 (CEST)
We should have done this a long time ago, the wiki FAQ always had duplicated content, even when the site was hosted in Mamario's servers. Delete the Wiki FAQ!!! mbc07 (talk)
OK, but seems counter to the change that started this (i.e. moving guides from site to wiki). Why is it better that only limited folks can maintain the FAQ? If it's the content duplication that's of concern we might want to get rid of the other FAQ, and preserve the editable one on the wiki.Kolano (talk) 04:06, 12 April 2013 (CEST)
The FAQ on the main website has several features that we want to preserve, most importantly internationalization. That's one of the reasons why I'm limiting who can edit the FAQ: every edit needs translators for more than 15 languages to update their versions of the FAQ. If one has to go, it won't be the one from the main website. I'm open to giving more people access to it though, it will never be completely open though. delroth (talk) 09:39, 12 April 2013 (CEST)
Deleted the wiki FAQ, and redirected to the mainsite FAQ. I have access, so if you see something just let me know. Delroth is going to be away for a while, but other devs have access to the site, so it shouldn't be too difficult to add someone if you ask. I see no reason why you guys (mbc07 and Kolano) couldn't be given access to the mainsite FAQ to help out. - MayImilae (talk) 22:51, 23 April 2013 (CEST)


According to Delroth, the new AX-HLE merger should fix the vast majority of DSP HLE issues. How are we going to update this? It's a ton of games, and I doubt we'll be able to get someone to test everything... - MayImilae (talk) 21:19, 2 April 2013 (CEST)

A rough approach would be filtering games that doesn't use AX UCode (Zelda, Mario Galaxy, etc.) and then crossing out all HLE problems in all game pages... It'll be easier to filter out games that doesn't use AX UCode than filtering games that use it... -mbc07 (talk)
I asked Delroth, and unfortunately he doesn't have a list like that. One of the other devs might though. - MayImilae (talk) 21:58, 2 April 2013 (CEST)
Yeah, this is why the various developer infobox fields never got filled in properly. They would have been what we'd need to filter on something like this.Kolano (talk) 22:13, 2 April 2013 (CEST)
Unfortunately we can't rely on that entirely. Skyward Sword uses AX. - MayImilae (talk) 22:20, 2 April 2013 (CEST)
There are a lot of HLE mentions on the Wiki though it's unclear how many of those ~2132 results are from test results and the like (If we can perform a regex search we can probably whittle that down to just the pages mentioning HLE in problems/compatibility). My guess would be that the HLE update will effect a bunch of titles that we never logged problems for though, so appropriately accounting for the update will still be problematic, even if we account for reviewing all the current HLE issues. I wonder if we could work out some scanning tools, similar to the ones for the title icon uploads to get a better DB of these sorts of wide-scale software types. There are various issues related to use of certain unsupported video codecs that might also be nice to scan for, I'm guessing there are other examples.Kolano (talk) 22:13, 2 April 2013 (CEST)


Now that we actually have access to the wiki on a basic level, I'm been investigating how to automate tasks here around the wiki. Stuff like updating the list of games, manipulating categories, on and on could be done wiki-wide with a script. We could potentially even kill spambots with it (or at least flag them to make clean up easier). There are all kinds of things we could do. Now obviously, I'm an artist, not a programmer, so my contributions to this are limited. But I can learn things quickly. Anyway, I think this could go a long way to help us save a ton of time in large scale modifications, and let us do things like updating game lists more often. For reference, here are some bots and scripts I found while looking around: Bot Status - Bot list sorted by edits - User Scripts List - User Scripts Tutorial.

Delroth and the devs brought this up, cause well, they are too lazy to do manual edits :P. Our needs would probably be better served by scripts than bots, but, having stuff done automatically might be nice sometimes. So, what do you guys think? Do you want bots and scripts, and if so, what would you want them for? - MayImilae (talk) 14:51, 14 December 2012 (CET)

Talking about bots, I wrote a simple script to update the Template:CurrentGitRevision page automatically when a commit is pushed to the Git repository. That should be one less thing to worry about. delroth (talk) 03:35, 5 January 2013 (CET)

My grocery list of scripts:

  • System to allow the revision template to understand GIT codes, restoring it's functionality from before the GIT migration
  • Script to collected and create GameIDs and direct them to relevant pages

I asked Delroth about the revision template recently. He said he could get it working with the new site in no time, but since that would cover only a tiny fraction of revisions, I told him to wait till he can put in a complete solution that ties to google code. To be honest I'd prefer the main site just be updated to go back all the way but eh, that isn't in their plans. - MayImilae (talk) 03:25, 7 January 2013 (CET)

I have a list of about 300 gameids which should redirect to existing Wiki pages. Could someone review and tell me if it's ok to mass-create these pages? delroth (talk) 19:54, 2 February 2013 (CET)

Talked with him about it in the channel. Everything either checks out or will create a double redirect. So, he'll upload it, and then we'll check the double redirects to fix any issues. Simple enough. - MayImilae (talk) 14:20, 3 February 2013 (CET)

I should actually be able to check for double redirects pretty easily. The bot will do it automatically. delroth (talk) 15:49, 3 February 2013 (CET)
Done! I also fixed all the other double redirects at the same time. delroth (talk) 07:46, 4 February 2013 (CET)

I also have some cron scripts listing stuff to do on the Wiki: for example:

  • GameIDs missing a redirection, from the "Go to Wiki" menu in the emulator
    • sXAP52, r8pj01, suke01:Capitalization on these ones is odd, we have an entries with appropriate caps, not clear what's with the lowercase letters
    • £×Uº²�, ŽÔç_ìÂ, èl9/C, +¾‹Ešn,#•Wõ�d:These have various odd characters.
    • GCOPDV, GBLPGL: The first 4 chars of these align with "GCOP52: Call of Duty: Finest Hour" and "GBLP52: Bloody Roar: Primal Fury" but I'm not clear they are the same.
    • GGCOSD: GCOS GC MultiGame DVD), GCOPDV:GCOS MultiGame DVD, MRRP01: New Super Mario Bros. Wii Retro Remix, GBLPGL:Xeno GC Homebrew Boot: These are various IDs associated with homemade multi-boots, or other homemade images. Not clear we should track these.
    • Most other residual ones I'm having trouble aligning to a known game title, they don't seem to show up on GameTDB.
  • All game pages which don't have a 6 chars GameID redirecting to that page
    • Peach's_Castle: Seems to have the invalid ID "00"
    • System_Menu: GameID for system menu wads is blank
    • Toy Wars:These don't have disk images and are just distributed as resources /w DOL files
    • Call_of_Duty:_Black_Ops/sandbox_(Wii): Sandbox pages should generally be isolated, there's no gameid for the sandbox
    • MaxPlay_Classic_Games_Volume_1: This game is unlicensed and steals a gameID from other titles typically "NHL HITZ 20-02: GNHE5d"
    • Channels and some WiiWare titles seem to use 4 character IDs, and aren't filtered from the 6 char list. Will need to avoid filtering the few non-Channel games, (i.e. History Channel ??? and Pokémon Channel). Dolphin seems to postfix these with "01", but was unclear how we want to handle them here.
Kolano, I talked with Delroth about the 4char GameIDs. Both the 4 and 6 character IDs are correct. The last two characters in a 6 character GameID is the publisher code. For WiiWare, Wii Channels, and Virtual Console games, Nintendo decided to detach the publisher code. Plus, the code is based on platform, not publisher. 01 NES, SNES, and N64 VC games, for example. The Dolphin devs decided to go for uniformity, and put the publisher code back in. So to Dolphin the GameID includes it, even though officially the GameID according to Nintendo does not. But it is official information from nintendo. - MayImilae (talk) 11:41, 7 February 2013 (CET)
Per that I guess we should have entries for both. There are likely some double redirects from when I first noticed this to clean-up, and the scripts here may need to be updated to also track the 4 char IDs.

Tell me if you need more. delroth (talk) 23:06, 3 February 2013 (CET)

Another thing I will automate: editing infoboxes to add the link to the forum thread when a forum thread exists. Trivial to do with access to the forum database, just needs some infobox template parsing... It's on my TODO for tomorrow. delroth (talk) 07:46, 4 February 2013 (CET)

One thing I'd like to get a bot/script to perform would be mass search and replaces. For instance, we noticed a frequent mis-capitalization of Single-player as Single-Player. It's easy enough to search and find most instances of this, but actually editing/saving each page is tedious.Kolano (talk) 07:17, 7 February 2013 (CET)

I second this. A find and replace script would be GREAT. - MayImilae (talk) 09:55, 7 February 2013 (CET)
It's already in PyWikipediaBot (the framework I'm using). Just tell me what mass replaces you want to do and I'll run the bot. delroth (talk) 14:44, 7 February 2013 (CET)
  • Single-Player > Single-player
  • Wiimote, wiimote > Wii Remote
Only in infoboxes or in the whole page text? Whole page text would be easier, but I can do both without too much of a problem. delroth (talk) 11:57, 8 February 2013 (CET)
Personally I'd prefer you keep it to just infoboxes. There are times where I use Wiimote, Wii Remote, etc etc as variation in pages so it doesn't sound dull. - MayImilae (talk) 14:13, 8 February 2013 (CET)
Wiimote should already be corrected in all infoboxes. Wiimote is not the appropriate name for the device though, so I'd personally prefer it be replaced everywhere. Though I don't really want to fight about it. The Single-player capitalization fix can be applied everywhere, but be careful about the capitalization (i.e. we don't want to capitalize lowercase single-player outside of infoboxes, but we would if it appears in an infobox. "Single-Player" to "Single-player" should be a safe global replacement though, if capitalization is respected).
Actually, Wiimote is used in dolphin for various settings, like Alternate Wiimote Timings. Wiimote should definitely NOT be replaced everywhere. - MayImilae (talk) 04:18, 10 February 2013 (CET)
That may be the case, but that just means Dolphin devs have failed to use the appropriate term for the device. It does unfortunately complicate the replacement though.

Noticed Major adding redirects to account for capitalization differences. Something to automate the creation of such might be nice, though I'm guessing there may be easier ways to account for such. Kolano (talk) 02:58, 19 February 2013 (CET)

I'd also like a script that could match instances of the issue {{{1}}} template on the used on the Wiki to the open issues on Google code. So we could identify closed issues for alignment with issue reporting on the Wiki, and provide consolidated reporting for open issues. Kolano (talk) 20:29, 25 February 2013 (CET)

Collapsed Navigation Templates

Currently the navigation template defaults to a collapsed state. I'm a bit confused by such, since that defeats their purpose of providing clear linkages to related series titles. Most of the navigation templates only take up a line or two of the display anyway, so I'm also not clear we're gaining a lot by having the collapse. Can we perhaps redesign the template to:

  • Purge the title row:
    • Purge the hide/show link or reposition it and default to show
      • If the hide/show functionality is preserved, I'd at least like to see the hide/show setting be set to a cookie, so it would apply across the navigation templates, rather than just the one on the current page.
    • Purge the "view" link, since I'm not clear it serves much purpose
    • Reposition the edit/discuss links to the upper-right corner (so they generally won't overlap/offset links, when appearing on the same line).

Please let me know your thoughts. Kolano (talk) 19:09, 10 March 2013 (CET)

I agree, the navigation should be shown by default. Having it collasped is just a hold over from wikipedia. But for us, it's always very small, and it's very handy to have. So I think it should be shown. As for your ideas... I like the title row, so I don't want to just remove it. As for the "view" link, it provides an easy link to the template itself, so it has some use. As for the rest... I don't really care. *shrug* - MayImilae (talk) 19:46, 10 March 2013 (CET)

Ok, did some tweaks: all navigation templates are expanded by default and "view" link was removed. I agree with MaJor regarding to the title row, it should stay as is. I won't implement a cookie to store "hide/show" preference because it would be a lot of work for something that shouldn't be cared about. And since the code used to implement the functionality of the hide/show buttons are shared by a lot of templates, I can't remove it from navbar without breaking the show/hide functionality of Test Entries and the "contents" chart. Also, moving the talk and edit links to the upper-right corner caused a lot of issues with the positioning of show/hide button, so I'm just leaving it in the default position. - mbc07 (talk)
View link is gone, but templates still remain collapsed by default, refer: Super Monkey Ball. Kolano (talk) 16:15, 11 March 2013 (CET)
Fixed for real now - mbc07 (talk)

Importing game banners on the Wiki

As you may have seen on the forums, I've been crowdsourcing the collect of game banner images (the 96x32 images used in the Dolphin game list). These images should probably be hosted somewhere on the wiki like the covers, but I don't know how you want to handle that. Could someone look into adding banners for a few games? I will then use a bot to import everything.

When the import will be done I will be able to add the banners to the new Dolphin website compatibility list: :) delroth (talk) 05:22, 5 February 2013 (CET)

A rough idea would be using the game ID as filename (like "G8ME01.png") and including the ID somewhere (like as an hidden parameter in Infobox VG). Banners maybe different based on release (NA/EU/JP), so, I think we should have a preference, like NA first, then EU, then JP. The 4th digit in the game ID reveal this (E for NA, P for EU and J for JP). Well, what I'm trying to say is: if the game has been released in all territories, use NA banner. If it was released only in Europe, use EU banner. And, if released only in japan, use JP banner.
Also, adding all banner images in a category would be nice, like [Category:Banner images]. Well, I'll try to exemplify this in a sandbox... mbc07 (talk)
I've thought about putting the banners in the infobox, but I haven't come up with a method that is actually useful. Let me explain. Our brains respond to visual stimuli far better than text. That's why a collection of icons on the desktop is better than a big list of words. Our brains are trained for this stuff. So, in the list inside the dolphin emulator, the job of the banners is to give a visual reference of the game, to exploit our how brains work and help us find stuff faster. On the wiki pages though, cover art already does that, and far better than the tiny banners. Banners on game pages would be kind of redundant. But we could use them in the same way that dolphin does... Banners would be pretty awesome in compatibility lists. Imagine the wii article with banners in it. It would give that quick visual reference that the lists need. I think it would be great there. - MayImilae (talk) 18:34, 6 February 2013 (CET)


Actually the banners wouldn't show up in the infobox with the covers, I proposed having Game ID as a hidden parameter thinking in easily getting this ID for use in other template, but this is completely out of question now (after some tests I found that there isn't any way of getting a parameter from infobox VG template in another template). So, my initial idea now is:

  • Have the Game ID as file name (like G8ME01.png), and add all banner images in a category (Category:Banner images)
  • Prefer NA banners, then EU banners, then JP banners
  • Add the banners in the main lists too (GameCube, Wii, etc.) -- Something like delroth is doing for the main site

Then, delroth could hotlink the banner images from wiki, this way we could share only one copy of the banner in the main site and in the wiki aswell. mbc07 (talk)

A user had started to gather banners here previously. The banners from his minor effort to do so are categorized as "Title images" and can be found. See them here, I've added John's recent upload to that category.

"Banner images" seems a more accurate category. We can move them to the new category, as we have only a few images uploaded... - mbc07 (talk)

My feedback here would be:

  • We'll need to decide if we want all the banner images or not, in some cases there may be 5 or 6 of them per game disc. Since we may be likely to only use one image I'm not clear it makes sense to capture them all.
  • If we wanted to use these on game pages I'd suggest they be tied into the "Release" section, where it may make sense to capture a title image per region.
Tried in a sandbox and the infobox got somewhat "ugly" (at least in my opinion). If we're going to use the banner in infobox, putting only one banner image in "see also" section (before the links) seem better. - mbc07 (talk)
  • Judging from our current banners, the images seem a bit overly compressed (even though we've re-saved them as PNG to avoid compounding artifacts). Likely not a big deal, but we should try to make sure to avoid compressing them further and increasing artifacts.
Well, from what I've seen, all banner images delroth got with "bannerget" were extracted directly from the Dolphin's cache file, so, it's compressed only one time. - mbc07 (talk)
  • Though I would like to see them on the game list pages, adding 600+ image loads to the page may have a significant impact on performance/load times. The list pages are already fairly slow today (I'm guessing from the many ratings loads), so we should be careful. Kolano (talk) 21:21, 6 February 2013 (CET)
Yep, this is true... Completely forgot the loading times when I suggested this - mbc07 (talk)
There might be a way to get this to be fast with a custom MediaWiki extension and some CSS sprites usage (basically, only one large image would be loaded for each list page). I could learn how to do that if you think it would be a nice addition to the compatibility lists. delroth (talk) 00:52, 7 February 2013 (CET)
The list table is rendered through MediaWiki markup, I'm unsure if we can mess CSS sprites with MediaWiki formatting without major issues. However, if this can be done without loading issues, the main list is the best way for having the banner images (better than in infobox VG) - mbc07 (talk)
This is a good point... Dialup user here so, a giant image would SUCK for me. Lots of smaller images are easier to cache. But a thousand banners on the wii page would suck no matter what for me. - MayImilae (talk) 04:50, 7 February 2013 (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? 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? - MayImilae (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. 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? - MayImilae (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. 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. - MayImilae (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... mbc07 (talk)

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.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. - MayImilae (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? Kolano (talk) 09:00, 17 September 2013 (CEST)
Fine with me. I don't know anything regarding the revised category names grouping though, sorry. - MayImilae (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. Kolano (talk) 04:50, 17 October 2013 (CEST)

OK, this should be done now, outside of the platform migration to the infoboxes. 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. 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. - MayImilae (talk) 12:28, 6 September 2013 (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?

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


Universal problems are buried

I know VC titles are pretty low on the totem pole, but they are pretty cool to play in Dolphin. That said, they are kind of a crapshoot. There are a lot of problems with these games. NES, SNES, Genesis, they all have universal issues spanning every game. But uh, the universal problems are only on the system pages. The virtual console page shows every title, and people just click the game in that and boom. It's convenient, but no one goes to the system pages where the universal problems are. No one ever sees the universal problems. So, I have two solutions I'd like to propose to fix this.

  • 1. A grid of buttons for systems on the Virtual Console page, sort of like the mainpage's. That way people can easily access pages for systems, and see the universal problems and stuff. Of course I'll have to dust off that gamepage project and get them up to snuff, but eh, I can do that.
  • 2. A universal issues template. Considering it would only have to copy paste text, it should be pretty simple. The only issue I can forsee is integrating it in with the layout of the pages (like how various problems have links in the nav). Might be worth ignoring that however. But yea, ideally, all we'd have to do is put {{universalproblems|SNES}} onto all the SNES game pages, and bam, we have a super easy way to change the universal problems across the board.

Any thoughts on these ideas? For or against? - MayImilae (talk) 20:09, 5 March 2013 (CET)

Hm, I liked... I can help with the templates, and if we change the main Virtual Console page to grid of buttons (like the main page), I can delete some crappy templates we've around here (some unfinished work that I didn't touch in the last 2 years -- completely useless now). Also, since we're going to do major changes in the main Virtual Console, we could implement also an infobox with common information about the service, like the infobox we got in GameCube and Wii page. Regardless of what we do, I'm in with this whole thing - mbc07 (talk) 22:29, 5 March 2013 (CET)
I'd also be on board for both changes. Sub-pages for VC systems will eliminate some of the template issues there (i.e. one can't edit the lists from the main page), and generating {{universalproblems}} templates will allow universal issues to be universally shown (though some special handling may be needed to get the edit links right). I'd also suggest adding sub-links below the "Virtual Console" link in the sidebar for the system pages, which would make them more quickly accessible. Kolano (talk) 00:43, 6 March 2013 (CET)

I hadn't forgotten about this, I just hadn't gotten around to implementing it. That ends now :D. First up is making the Virtual Console list use thumbnails. See Virtual Console/sandbox1. There are a couple of things I'd like you guys' input on.

  • Thumbnail arrangement - I took a very different approach here than what the main page does. I really like it. It's much more flexible, able to span all of a giant widescreen monitor or compress down to be easy to use on a phone in portrait. And it matches the nature of the text. I like it so much I'd like to use it on the mainpage if possible. What do you guys think? I could always go with what the mainpage does instead (centered, 5x2 arrangement).
  • Arcade versus Virtual Console Arcade - Nintendo calls it the "Virtual Console Arcade", but here on the wiki it's always been just "Arcade". Any objections to changing it to Virtual Console Arcade? I'd rather like to do that.
  • The Platforms template lacks a lot of options that I could use. See wikipedia:Virtual Console. Any objections if I add a whole bunch?

Random block of text so my signature isn't in the bullet points and it's easier to comment beneath me. - MayImilae (talk) 18:34, 19 July 2013 (CEST)

The revised VC page looks nice...

  • It may be better if the images were centered rather than right aligned. I think it should be possible to set that up and still have them flow to an arbitrary width.
  • I had generally preferred to just use "Arcade" since that better aligns with our naming of the other platforms (i.e. it's not "Virtual Console Sega Master System"), but if you want to align with the Nintendo naming that's fine with me.
  • Not quite clear what other options you are after, we seem to cover most of what's used on the Wikipedia sidebar...
    • Launch date would seem to be equivalent to our "Retail availability"
    • The "platform" option seems pointless for us, since we'll only cover Wii VC titles.
    • We have a website option

Kolano (talk) 17:17, 20 July 2013 (CEST)

NICE! I had wanted to center it, but I didn't know how to center it while keeping the flexible width. Thanks. Any problems with applying this to the main page? - MayImilae (talk) 19:11, 20 July 2013 (CEST)
Done Kolano (talk) 21:52, 20 July 2013 (CEST)

I liked the changes. For me we already can take the new page out of the sandbox and replace the older one. For the Arcade vs Virtual Console Arcade, I also prefer just "Arcade". Furthermore, the new grid we're using in Virtual Console and Main page could be tweaked a bit more so all of them use the same size.

Since we started changing the things related to virtual console pages and that I'm getting my vacation soon, the chances of starting the creation of the global problems template this week are pretty high, but I'm not sure how they'll work. Before I start, let me expose what I'll try to code (and let me know of any objection):

  • In the main page VC we'll have a simple call to {{globalproblems}}. This call will show the global problems (like we have now).
  • In every subpage (N64, SNES, etc.) we'll have a simple call to {{globalproblems|<insert system here>}}. This call will show the global problems of that specific platform.
  • (Just an idea right now) In every VC game page, we'll have a call to the system, like the item above... This way we show the global problems in the game page too. Im not sure in this item, maybe we get too much redundancy?

Let'me know what you guys think, I'll do my best to make this template this week... mbc07 (talk)

Well, I disagree with you guys on the arcade, as "Virtual Console Arcade" is an exception to the systems rule, but alright, I won't fight on it. I have no idea what I'll do with that page though, if I can't use the virtual console arcade thumbnail and description... Anyway, as for the VC page, I'll go ahead and port it over. I don't know what to do about the grid size problem. I tried a bunch of stuff and didn't really get anywhere; it's still slightly off. Any suggestions? Lastly, the global problems template: You didn't mention where the editing of these problems takes place. I assume it would be in template:globalproblems? The template has all the systems global problems in one place, and you can edit them all there? As for having universal problems on each gamepage, we'll have to talk about that. It is reduntant, but without it users that just do a search to bring up games (a very common practice) would never see the global problems. I'm in favor of it (if we can get it to work well), so let's see what Kolano thinks and go from there. - MayImilae (talk) 05:27, 22 July 2013 (CEST)
Oh yea, almost forgot. I'm not going to mess with the virtual console ratings templates. I know the plan is to make it so you can just hit edit a VC system page and edit it from there, just like you can on the Wii and GC pages, but uh, I'm afraid that if I do it I'm going to break everything. And honestly, with the compatibility page on the main site linking to those templates, it probably will regardless. When changing it double check the main page's compatibility page, and if they break send a PM to delroth about it, or let me know and I'll tell him. - MayImilae (talk) 05:40, 22 July 2013 (CEST)

The VC ratings templates can (and probably will) be deprecated as soon as we merge the new page from sandbox, because the only functionality they provided was the master list in our old VC page (that is result of unfinished work: ugly and can't be easily sorted). I can do the move, but I prefer to wait the new VC page getting out of the sandbox. After that, the lists would work the same way of GC and Wii lists.

About the global problems, yes, we add the problems one time in {{globalproblems}} and the template code does the linking. We can have sections for problems of every platform and global problems all in the main {{globalproblems}} or have subsections for every platform ({{globalproblems/NES}}, {{globalproblems/N64}}, etc -- like what we do with navigation template). mbc07 (talk)

  • The VC page needs a revision to keep the centering appropriate when part of the grid overlaps the sidebar. Should be similar to changes applied for similar reasons to the Version Compatibility graphs.
  • If we reduce the padding there to 2px, we probably should do so on the home page too.

Kolano (talk) 18:58, 22 July 2013 (CEST)

MediaWiki upgrade

Hey everyone. Working on upgrading MediaWiki in order to keep up with the latest version. I'm also going to work on a DB engine migration soonish (in the next few hours). Ignore the errors you see for the next 12h. If you notice some errors 12h from now, please let me know and I'll do my best to fix them ASAP. delroth (talk) 22:16, 18 June 2013 (CEST)

After 3h spent moving data from MySQL to PostgreSQL and fixing errors (seriously, that DB had so much crap in it... constraints were completely broken because MySQL did not enforce them), everything should be working again. If you notice any error, please send me an email (, I might not look at this page. delroth (talk) 01:27, 19 June 2013 (CEST)
And if it's a design/visual issue, try to Ctrl+F5 and Ctrl+R before reporting the error. delroth (talk) 01:32, 19 June 2013 (CEST)

Started noticing errors when updating images on the site. Some examples:

I saw some SQL related errors when I updated BillysBootCampWii.jpg, but couldn't replicate them. Kolano (talk) 10:20, 20 June 2013 (CEST)

Fixed delroth (talk) 13:50, 29 June 2013 (CEST)

Also: started to move everything Dolphin related over SSL. All accesses to should now be automatically redirected to https. If you notice any problem caused by that, please let me know (email). delroth (talk) 13:50, 29 June 2013 (CEST)

uDraw Wiimote / Inputs Handling

I read a bunch of reviews on the udraw games, and they all appear to be the same: The wiimote is not used any at all in the udraw games, it only provides power and connectivity. There is another accessory that works this way: the classic controller. Throughout the wiki, the classic controller is alone, and shown as just "Classic Controller" even though it requires a wiimote to power and provide connectivity. So, for that reason, I believe the udraw games should only have the udraw gametablet in the controller section. Any objections? - MayImilae (talk) 01:41, 21 May 2013 (CEST)

Not sure. Regarding the Classic Controller, I'd kind of want to list the Wii Remote as well as the Classic Controller. That seems to be the way it's handled now outside of a few Virtual Console titles, though that may be due those games providing Wii Remote input too. I do apologize about renaming GameTablet to just Tablet, which I did to align with the regex's in infobox that pick up on the string "uDraw Tablet". Since noticing it's official name is the uDraw GameTablet I feel it should be named that way, but didn't want to muck around with all the related pages last night (it is on my "to do" list though).

In general since, per my current understanding, even if one has a uDraw Tablet you also need a Wii Remote to play I'm disprone to not list it as well as the uDraw. Honestly, we need a better format to distinguish optional from non-optional accessories, since I think there are a number of games that have Wii Remote + Nunchuk, where the Nunchuk is actually optional. In these cases the Wii Remote isn't optional though, so I'm prone to list it. Kolano (talk) 06:44, 21 May 2013 (CEST)

Well, the way I view it is control combinations. That's what's actually useful. Wiimote + Nunchuk makes sense for games that use them both. But there is even a Wii game that uses just the nunchuk and ignores the wiimote entirely, and it lists only the nunchuk (unless you changed it and I didn't notice). The other approach is to list the devices, but that really sucks in games like smash brothers, which use a wide variety of combinations. So yea... Seems we disagree. What now? - MayImilae (talk) 09:49, 21 May 2013 (CEST)

Yeah, I'm not sure yet. Typically I've just been going by the listing on the rear of the NA/EU boxes that provides icons for each device supported. Beyond that I haven't been worrying about how the devices are used much, since it's hard to know exactly which control schemes are possible (i.e. is the nunchuk optional, can the nunchuk be used by itself, etc.) without the game. If there is a game that lists only the nunchuk now I would prefer to list it as "Wii Mote + Nunchuk", since I'd guess that's what the box would indicate. Maybe this could be resolved by providing separate input and control scheme rows, or perhaps just some clearer rules on how to indicate different control schemes (i.e. perhaps enable unbolding optional controls, though in this case the Wii Remote isn't really optional, and actually I'd guess based on how it slides into the uDraw that the buttons on the Wii Remote are used in games). These devices are different than things like the Wii Balance Board though, since they do use the Wii Remote for Bluetooth communication.

One good thing to capture, if we do try to tackle control schemes would be games that support sideways Wii Remotes vs standard use, since there are clearly Dolphin options related to such.Kolano (talk) 16:52, 21 May 2013 (CEST)

I looked up reviews on almost all of the udraw games. I couldn't find a single one that used the buttons on the Wii Remote. Reviewers even commented about this, for example asking why a platformer game was controlled with the stylus when there was a dpad right there. To my knowledge, the udraw games do not use the wii remote at all. And yea, I agree with you on the sideways wiimote bit. I never really found a way to handle it though. Well, I really like the control config setup. It's very useful. And it usually isn't that difficult to figure out "Wiimote and nuchuk" 99% of the time means "wiimote + nunchuk" for example. Well, perhaps we should move this to the general discussions page, and try to get mbc07's opinion? - MayImilae (talk) 00:34, 22 May 2013 (CEST)

Well, I think we should list all required inputs. For example, Classic controller needs Wii Remote to function properly, so, list Classic Controller and Wiimote, the same for uDraw tablet. Also, my suggestion for required and optional inputs would be using icons for all inputs (even the optionals), something like what we have on WiiBrew wiki (here is an example -- the infobox has a lot of icons, we could get only input related ones). This "design" can also provide visual feedback about how many controllers are supported in multiplayer and if the game uses sideways wiimote, etc. This would require a major rewrite of the wiki pages, but I think it's our best bet, since we don't have a standard for input listings. Also, since we don't have a documented "standard" right now, we can create one now and list it in Project:Wiki conventions. Furthermore, the input icons used in WiiBrew are using Creative Commons license, we could use (or create our icons based on it) without copyright/licensing issues... mbc07 (talk)

I disagree on the required inputs bit. Especially for VC games and the like, it seems rather silly to list the Wii Remote when it does absolutely nothing at all ever for an entire class of games. Also, we have a standard, the combinations style is everywhere :P. Oh well, seems I'm outvoted on this. And it would be easier... Well, if we're going to have it just list the devices instead of combinations, what do we do with cases where things are complicated? The whole combinations system came about because of games like Super Smash Bros. Brawl where one device can perform multiple functions. Is there anyway to address this? - MayImilae (talk) 01:50, 25 May 2013 (CEST)

Well, in this case, List only uDraw Game Tablet and Classic Controller separated and add the combination system to all pages (to the VC games too). Whatever we do, add documentation to it somewhere to prevent future issues. Another option, if we're going to use the icons, is "merging" normal icons to represent combinations (like wiimote + nunchuck), but in this case, we leave Classic controller and uDraw as a separate icon, without combining them with wiimote... mbc07 (talk)

Forum Link Issues with Ampersand

It seems when content from the wiki is pulled into the forum ampersands in links are not escaped properly (i.e. "&" > "%26"). This causes the links to either be broken, or in some cases such as We Ski & Snowboard an entirely wrong page to be linked. Kolano (talk) 16:38, 23 April 2013 (CEST)

We should inform delroth, since the links works and are parsed correctly when we are in the wiki, this probably is an issue with the "wiki => forum" rendering engine. mbc07 (talk)
There is a bit of a bleh situation going on right now... delroth isn't available to be contacted. It will be a while. - MayImilae (talk) 22:04, 23 April 2013 (CEST)

DB Error

Getting a DB error uploading images...

A database query syntax error has occurred. This may indicate a bug in the software. The last attempted database query was: (SQL query hidden) from within function "UploadStash::stashFile". Database returned error "42703: ERROR: column "us_props" of relation "uploadstash" does not exist LINE 1: ...stash" (us_id,us_user,us_key,us_orig_path,us_path,us_props,u... ^ ".Kolano (talk) 08:42, 11 September 2013 (CEST)

This error is preventing me from adding a image to Super Mario Bros.: The Lost Levels. Might be related to the issue patched in,, but I'm not sure. Kolano (talk) 19:27, 11 September 2013 (CEST)

Hello, I had this problem. It is a result of using Postgres. There was a bug reported, but I'm not sure that it ever got into the official bug tracker. You can read the discussion here: I had to go into the database and run: alter table mediawiki.uploadstash add column us_props bytea null;

And then I also had to edit 'includes/upload/UploadStash.php' and change: 'us_props' => serialize( $fileProps ), to: 'us_props' => serialize( pg_unescape_bytea($fileProps) ),

And then if I wanted to upload DJVU files, I had to edit 'includes/media/DjVu.php': Change getMetaTree(...):

      $tree = new SimpleXMLElement( $metadata );


	$tree = new SimpleXMLElement( $metadata );
   } catch( Exception $e ) {
	$tree = new SimpleXMLElement( pg_unescape_bytea($metadata) );

Whoever said that Mediawiki works with PostgreSQL is wrong/lying.

Reproduced. Apparently it happens in any file with a space in the name. Which is weird, since that has worked for a long time, and I even did it just a little while ago. *shrug*. I notified Parlane, and he confirmed what the anonymous poster above said. As Parlane put it: "basically there is a fix in the pipeline but the pipes are moving slow as fuck ?". I guess we need to just avoid using spaces in filenames until mediawiki fixes this? - MayImilae (talk) 08:02, 7 January 2014 (CET)
Oh, that was awesome. Since the fix was already done and just not committed to mediawiki master, Matt_P just applied it himself. It's fixed :D. Give it a try Kolano. And thanks anonymous guy, whoever you are. - MayImilae (talk) 08:27, 7 January 2014 (CET)

Ratings Changes

As you know, our ratings are old. Very old. I'll paste them here for memory sake.

Stars0.png Unknown: Has not been tested yet
Stars1.png Broken: Crashes when booting
Stars2.png Intro/Menu: Hangs/crashes somewhere between booting and starting
Stars3.png Starts: Starts, maybe even plays well, but crashes or major graphical/audio glitches
Stars4.png Playable: Runs well, only minor graphical or audio glitches. Games can be played all the way through
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.

Stars0.png Unknown: Has not been tested yet
Stars1.png Crashes when booting
Stars2.png Cannot reach gameplay but can reach menus
Stars3.png Major unsolvable issues
Stars4.png Minor unsolvable issues or fixable major issues
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:

Stars0.png Untested
Stars1.png Does not pass the main menus
Stars2.png Unplayable or cannot be completed
Stars3.png Main mode can be completed, but has major glitches/crashes or missing modes
Stars4.png Minor issues
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. - MayImilae (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 - mbc07 (talk)
I agree with mbc07 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. 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. Kolano (talk) 21:52, 27 August 2013 (CEST)

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.
On the actual ratings though, I find that "Level 3" (i.e. 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? incassum (talk) 21:00, 14 January 2014 (CET)

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. 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? 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? - MayImilae (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. 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? - MayImilae (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. 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. - MayImilae (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... mbc07 (talk)

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 . 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. 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. Kolano (talk) 07:14, 7 November 2014 (CET)


16:9 and F-Zero GX's custom cars problem restoration

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. - MayImilae (talk) 07:48, 4 November 2015 (CET)

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? 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... - MayImilae (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. 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? Lucario (talk) 11:55, 4 November 2015 (CET)
"Emulation Information and Misconceptions"? 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? - mbc07 (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. --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. --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! 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! - MayImilae (talk) 11:33, 9 November 2015 (CET)
Just to make sure, are you suggesting Emulation Issues or you're OK with Emulation Information? - mbc07 (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. --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 MayImilae specifically about her thoughts of the new section naming. - mbc07 (talk)
Oh! I'm sorry! I meant Emulation Information. - MayImilae (talk) 05:35, 10 November 2015 (CET)

16:9 / Outdated Banners

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. - mbc07 (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. --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.

*sigh* 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 (MayImilae, 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 - mbc07 (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 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 {{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. - mbc07 (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 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 Lucario seem to have disapproval of my attempted improvements. Kolano is showing concern but it seems he is willing to see how I revise my implementations to look nicer. --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 (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 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.

--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). mbc07 (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. --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. --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 v1, 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 here taking Interactive Multi Game Demo Disc v1 as a base. Should I start implementing this for every article about compilation discs contents or does the table need work? --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. - mbc07 (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? - MayImilae (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). - mbc07 (talk)
It's position doesn't bother me one way or the other. To hopefully build consensus I'll say list them first. 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! - MayImilae (talk) 11:32, 18 November 2015 (CET)

Config Template Slight Wording Tweak

After having a talk with Kolano about having my confusion cleared up what should be included in the configuration section of each disc wiki page, I think 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? --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. - MayImilae (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. --Wildgoosespeeder (talk) 09:43, 29 April 2015 (CEST)

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 {{GlobalProblems/VirtualConsole}}, like this:
=== 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> ===

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? mbc07 (talk)

Forgot something, the placement: Global Problems should be before or after the Problems section? mbc07 (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. - MayImilae (talk) 06:32, 10 August 2013 (CEST)

So mbc07, 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? - MayImilae (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. mbc07 (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. 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... mbc07 (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... mbc07 (talk)

I could ask delroth 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. - MayImilae (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:

{{GlobalProblems/<system>}} <!-- To edit the <system> VC Global Problems, navigate to "Template:GlobalProblems/<system>" (copy to the search box)-->

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? mbc07 (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 mbc07? You are more involved with the template. - MayImilae (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... mbc07 (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. 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. - MayImilae (talk) 06:13, 6 August 2013 (CEST)

Purge CPU Arch Indicators

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. Kolano (talk) 04:24, 10 October 2015 (CEST)

I'm fine with this. We don't support 320bit on any platform now. - MayImilae (talk) 09:50, 10 October 2015 (CEST)

Global Problems Template

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... mbc07 (talk)

We need to get this documented on the Global Problems template docs. Kolano (talk) 08:24, 6 October 2015 (CEST)

Performance Addition to Game Wiki Pages

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? - MayImilae (talk) 17:11, 26 April 2015 (CEST)

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. --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. - MayImilae (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 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. --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. 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...) - MayImilae (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! - MayImilae (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. --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! --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? - MayImilae (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. --Wildgoosespeeder (talk) 10:30, 10 May 2015 (CEST)

3D Support

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? - MayImilae (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. - mbc07 (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.) 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. - MayImilae (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.Kolano (talk) 08:24, 6 October 2015 (CEST)

Game .ini Documentation?

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

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

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

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


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


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

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

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

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

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

Remember what the wiki conventions say?

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

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

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

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

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

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

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

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

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

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

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


Infobox improvement

One of the things I used to do in my free time was hit random page and try and tidy up the infoboxes, since a lot of them were (and still are) a cluttered mess that's hard to read when editing. The changes that I would do are as follows:

  • Space them out evenly. The text box for editing in my case has always had even spaced characters, so lining up the = signs made it a lot easier visually to see what you're changing, and was generally more inviting. This would also extend to the config template for the same reasoning, though since the config entries vary wildly in name length, I understand that it quickly gets out of control.
  • Change the ordering of entries in the template to match how it looks on the final page, as they can be scrambled.
  • Check that release dates are correct. For this I usually consider GameFAQs the most trusted source, since they are very methodical and include KO/AUS entries that Wikipedia usually ignores. Sometimes the two can conflict though, compare the NA release of Wario World on Wikipedia and GameFAQs as an example.
  • Put dates and publishers in chronological order, as specified by the conventions. The vgrelease template defaults to JP/NA/EU/AUS/KO etc, which obviously isn't the order that every game gets its international releases in, but regardless a lot of pages have the data haphazardly inserted into the template causing inconsistent ordering.

Here's a typical example of how the changes looked. My question is, should I continue doing this? And if I do, is there anything else I should be changing or taking into account? It didn't seem like anyone cared either way at the time, and besides the dates it doesn't change the look of the page externally. I realize that there are bots now too, but I can only see them being practical in the first case; the latter three are a bit more complex, and will probably need human eyes.

Also can someone confirm the equal character spacing while editing is really universal? If it's not then 1 can be disregarded. - Xerxes (talk) 10:16, 25 November 2016 (CET)

Please feel free to move forward with this. I've known it's needed for a while, but had been holding off on it till a more complete set of title pages was in place. Though some progress has been made there, that may take another year or more to complete, so perhaps we don't want to wait. Uniform character spacing should be nearly universal, outside of perhaps a few oddball browsers/platforms lacking appropriate monospaced fonts. Kolano (talk) 19:38, 25 November 2016 (CET)

Problems section automation

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

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

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

{{Problems/VP6 Videos}}

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

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

== Problems ==

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

{{Problems/VP6 Videos}}

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


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

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

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

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

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

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

Category Intersection Search

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

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

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

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

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

5.0 announcement

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

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

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

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

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

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

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

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

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