6,906
edits
 |
Progress Continues
We've already had 21529 updates since Dolphin 5.0. Keep up with Dolphin's continuing progress through the Dolphin Blog: February, March, and April 2024 Dolphin Progress Report. |
 |
The Dolphin Emulator Wiki needs your help! Dolphin can play thousands of games, and changes are happening all the time. Help us keep up! Join in and help us make this the best resource for Dolphin. |
Project:General Discussions: Difference between revisions
Jump to navigation
Jump to search
→Global Replacement Request
(Username rename (Jhonn => mbc07)) |
|||
| (12 intermediate revisions by 3 users not shown) | |||
| Line 2: | Line 2: | ||
== Open Discussions == | == Open Discussions == | ||
=== Global Replacement Request === | |||
A spot to capture global replacement requests: | |||
* Update testing/entry template to always include "tester=" field. [[User:Kolano|Kolano]] ([[User talk:Kolano|talk]]) 01:36, 29 May 2015 (CEST) | |||
=== Titles without GameINI entries vs Rating === | === Titles without GameINI entries vs Rating === | ||
Okay, I'll get straight to the point. I don't think that problems caused due incorrect configuration (e.g. a non-default setting or a title with missing GameINI) should affect the rating of such title. Since we have established that entries under Problems section '''do affect''' the rating, my proposal is moving those entries related to issues that happen due incorrect configuration to the Emulation Information (as it's caused due bad config, not due an inaccuracy of the emulator) and leave the Problems section just for problems that will happen regardless of the settings (these are the real problems to my understanding). Given how the wiki evolved those years this feel natural to me (e.g. we already do the same with entries of enhancements that causes issues being on Enhancements instead of the Problems section) and I think it would at least alleviate the issues we have with the current rating system. Some "real-world" examples of what I'm proposing can be seen in [[Amazon Instant Video Channel]], [[Crunchyroll Channel]], [[Hulu Plus Channel]], [[YouTube Channel]] and [[Super Smash Bros. Melee]]. - [[User:mbc07|mbc07]] ([[User talk:mbc07|talk]]) 01:56, 13 March 2017 (CET) | Okay, I'll get straight to the point. I don't think that problems caused due incorrect configuration (e.g. a non-default setting or a title with missing GameINI) should affect the rating of such title. Since we have established that entries under Problems section '''do affect''' the rating, my proposal is moving those entries related to issues that happen due incorrect configuration to the Emulation Information (as it's caused due bad config, not due an inaccuracy of the emulator) and leave the Problems section just for problems that will happen regardless of the settings (these are the real problems to my understanding). Given how the wiki evolved those years this feel natural to me (e.g. we already do the same with entries of enhancements that causes issues being on Enhancements instead of the Problems section) and I think it would at least alleviate the issues we have with the current rating system. Some "real-world" examples of what I'm proposing can be seen in [[Amazon Instant Video Channel]], [[Crunchyroll Channel]], [[Hulu Plus Channel]], [[YouTube Channel]] and [[Super Smash Bros. Melee]]. - [[User:mbc07|mbc07]] ([[User talk:mbc07|talk]]) 01:56, 13 March 2017 (CET) | ||
| Line 14: | Line 18: | ||
::We would still cross those entries when the INI get updated and purge them out when a new stable version is released, and for cases such as Super Smash Bros Melee/Brawl (EFB2RAM/Real XFB) the related entry would just live here in the Emulation Information indefinitely. | ::We would still cross those entries when the INI get updated and purge them out when a new stable version is released, and for cases such as Super Smash Bros Melee/Brawl (EFB2RAM/Real XFB) the related entry would just live here in the Emulation Information indefinitely. | ||
::It would also finally put some consistency on our compatibility charts, for example, we have nearly 70% of titles with a "Playable" rating but I bet at least 20% of those already are "Perfect" for a long time but are "stuck" at the 4 stars rating anyway just because the user needs to manually adjust something with some mouse clicks in the meantime the GameINI doesn't get updated or in cases the GameINI probably never will be updated (such as Smash Bros). | ::It would also finally put some consistency on our compatibility charts, for example, we have nearly 70% of titles with a "Playable" rating but I bet at least 20% of those already are "Perfect" for a long time but are "stuck" at the 4 stars rating anyway just because the user needs to manually adjust something with some mouse clicks in the meantime the GameINI doesn't get updated or in cases the GameINI probably never will be updated (such as Smash Bros). | ||
:: TL;DR that's just another issue with our stone-age rating system that's bugging me for a long time and I strongly think this change would greatly improve the consistency of the current system without requiring drastic changes on the wiki, especially after the previous attempts which didn't go anywhere (e.g. the relabeling of the ratings from [[User: | :: TL;DR that's just another issue with our stone-age rating system that's bugging me for a long time and I strongly think this change would greatly improve the consistency of the current system without requiring drastic changes on the wiki, especially after the previous attempts which didn't go anywhere (e.g. the relabeling of the ratings from [[User:MayImilae|MayImilae]], the 3-star rating from myself or that "blue stars" thing from [[User:Lucario|Lucario]]) - [[User:mbc07|mbc07]] ([[User talk:mbc07|talk]]) 06:37, 16 March 2017 (CET) | ||
::: We haven't even discussed about "blue stars" yet. I've been working on it but I can't seem to get it working the way I want it to yet, hence why I didn't feel like starting a discussion about it yet. The blue stars was supposed to avoid misleading the users thinking there'd be no (or not as much) issues with default settings. Users will quickly notice its color before they even look at how many stars there are and being misled. [[User:Lucario|Lucario]] ([[User talk:Lucario|talk]]) 00:16, 18 March 2017 (CET) | ::: We haven't even discussed about "blue stars" yet. I've been working on it but I can't seem to get it working the way I want it to yet, hence why I didn't feel like starting a discussion about it yet. The blue stars was supposed to avoid misleading the users thinking there'd be no (or not as much) issues with default settings. Users will quickly notice its color before they even look at how many stars there are and being misled. [[User:Lucario|Lucario]] ([[User talk:Lucario|talk]]) 00:16, 18 March 2017 (CET) | ||
::::5% of the population has some form of color blindness... - [[User: | ::::5% of the population has some form of color blindness... - [[User:MayImilae|MayImilae]] ([[User talk:MayImilae|talk]]) 03:48, 24 March 2017 (CET) | ||
:::::Now that you mention it, I've ran blue and yellow stars into several color blind simulators and I was still able to distringuish between them just fine. Also there is new text "(configured)" appended next to rating text that'll take readers to the Configuration section to see how it ended up perfect or having lesser issues. (In case you were out of loop, notice that [[Super Smash Bros. Melee/sandbox]] has blue stars, it's static ATM) If a color blind user is still unable to distinguish between the blue and yellow stars he can always look at whether there is text "(configured)" appended next to rating text or not. [[User:Lucario|Lucario]] ([[User talk:Lucario|talk]]) 07:20, 24 March 2017 (CET) | :::::Now that you mention it, I've ran blue and yellow stars into several color blind simulators and I was still able to distringuish between them just fine. Also there is new text "(configured)" appended next to rating text that'll take readers to the Configuration section to see how it ended up perfect or having lesser issues. (In case you were out of loop, notice that [[Super Smash Bros. Melee/sandbox]] has blue stars, it's static ATM) If a color blind user is still unable to distinguish between the blue and yellow stars he can always look at whether there is text "(configured)" appended next to rating text or not. [[User:Lucario|Lucario]] ([[User talk:Lucario|talk]]) 07:20, 24 March 2017 (CET) | ||
| Line 25: | Line 29: | ||
:: I still feel it will be bad for users to see titles rated as 5 star, play the game and face errors, and then fight us here on the perfect rating. I'd much prefer to focus on actually getting the INI updates made than lots of revisions here to account for things differently. [[User:Kolano|Kolano]] ([[User talk:Kolano|talk]]) 21:02, 17 March 2017 (CET) | :: I still feel it will be bad for users to see titles rated as 5 star, play the game and face errors, and then fight us here on the perfect rating. I'd much prefer to focus on actually getting the INI updates made than lots of revisions here to account for things differently. [[User:Kolano|Kolano]] ([[User talk:Kolano|talk]]) 21:02, 17 March 2017 (CET) | ||
:Ack! Sorry for replying so late, I've been super busy IRL! So um... I'm opposed. If a user loads up a game, and encounters a problem, they should find the solution in the problems section (or the emulation section if it is a game bug or something), whether it is their fault or not. Remember, I support keeping problems that can still occur if the graphics config is opened (suitably labeled) - what's most important to me is informing users. - [[User: | :Ack! Sorry for replying so late, I've been super busy IRL! So um... I'm opposed. If a user loads up a game, and encounters a problem, they should find the solution in the problems section (or the emulation section if it is a game bug or something), whether it is their fault or not. Remember, I support keeping problems that can still occur if the graphics config is opened (suitably labeled) - what's most important to me is informing users. - [[User:MayImilae|MayImilae]] ([[User talk:MayImilae|talk]]) 03:48, 24 March 2017 (CET) | ||
=== Problems / Global Problems Merging === | === Problems / Global Problems Merging === | ||
| Line 56: | Line 60: | ||
:::::::::: I'm fine with Problem template going official now. [[User:Lucario|Lucario]] ([[User talk:Lucario|talk]]) 23:16, 29 November 2016 (CET) | :::::::::: I'm fine with Problem template going official now. [[User:Lucario|Lucario]] ([[User talk:Lucario|talk]]) 23:16, 29 November 2016 (CET) | ||
=== MD5 / GameID capture === | === MD5 / GameID capture === | ||
| Line 72: | Line 72: | ||
: Yeah, that came up in the discussion on IRC last night. We can get a near complete set of them for GC titles from Redump.org if needed though GameTDB likely has the same set for those, but those for Wii titles seem to be less available (and possibly unconfirmed where they do exist). [[User:Kolano|Kolano]] ([[User talk:Kolano|talk]]) 00:22, 30 September 2014 (CEST) | : Yeah, that came up in the discussion on IRC last night. We can get a near complete set of them for GC titles from Redump.org if needed though GameTDB likely has the same set for those, but those for Wii titles seem to be less available (and possibly unconfirmed where they do exist). [[User:Kolano|Kolano]] ([[User talk:Kolano|talk]]) 00:22, 30 September 2014 (CEST) | ||
I'm a little worried about this, to be honest. We have no way to confirm MD5s, so essentially we'll be relying on our sources, which are incomplete and may be wrong themselves. I'm not against the idea, just, I wish there was a way to be sure. A Wii homebrew program or something to calculate MD5s to build from on our own perhaps? I don't know. Any time we put up information that can't be verified, it makes me nervous. It could be wrong and we'd neeeever know it. - [[User: | I'm a little worried about this, to be honest. We have no way to confirm MD5s, so essentially we'll be relying on our sources, which are incomplete and may be wrong themselves. I'm not against the idea, just, I wish there was a way to be sure. A Wii homebrew program or something to calculate MD5s to build from on our own perhaps? I don't know. Any time we put up information that can't be verified, it makes me nervous. It could be wrong and we'd neeeever know it. - [[User:MayImilae|MayImilae]] ([[User talk:MayImilae|talk]]) 08:05, 2 October 2014 (CEST) | ||
:If this gets implemented, which I'm for, could we record if it's a SL or DL disc as well? [[User:Zephyrsurfer|Zephyrsurfer]] ([[User talk:Zephyrsurfer|talk]]) 10:18, 12 November 2014 (CET) | :If this gets implemented, which I'm for, could we record if it's a SL or DL disc as well? [[User:Zephyrsurfer|Zephyrsurfer]] ([[User talk:Zephyrsurfer|talk]]) 10:18, 12 November 2014 (CET) | ||
| Line 95: | Line 95: | ||
== Recent Discussions == | == Recent Discussions == | ||
Below is listed of recently concluded discussions. You can [[Project:General_Discussions/Archive|search the archive]] for what was discussed since General Discussions page was created. | Below is listed of recently concluded discussions. You can [[Project:General_Discussions/Archive|search the archive]] for what was discussed since General Discussions page was created. | ||
=== Proposed expansion for Wii GameIDs === | |||
The ID6 format used by GameCube GameIDs fails to properly represent all of the information that a full Wii TMD contains. As an example, the ID [[SVTEXS]] is assumed to represent all the game identifiable information for [[BIT.TRIP Complete]] that can be guaranteed to exist. However, an actually complete ID would be 00010000535654455853r00. This presents the full 18 hex digit Title ID, as well as the title version information from the TMD file. The "r" separator between the full ID and the title version is already in use by one of the GameINIs that ship with Dolphin, which is why I'm suggesting it be used. [https://github.com/dolphin-emu/dolphin/blob/master/Data/Sys/GameSettings/0000000100000002r1.ini Default GameINI for 0000000100000002r1], known as the [[Wii Startup Menu]] on the wiki. Properly representing IDs in this format will allow us to almost guarantee that we send users to the correct page for the Title they're trying to get information on. Including the Title Version allows for proper distinction when multiple revisions of a Title need their own pages, IE: [[Wii Menu]] and [[Wii Startup Menu]]. Using hexadecimal digits instead of trying to represent them as ASCII GameIDs allows for displaying the Title IDs for the WADs found within the [[Wii Backup Disc]] properly. Instead of trying to figure out to make a page titled [[kVß.02]] we could just make one named 000100006b56df1e0002r00. For a less specific usage case, adding TitleIDs for any Wii DLC will be impossible without using this format. All of their TitleIDs start with a lowercase letter, which is not allowed for MediaWiki pages. - [[User:PowerKitten|PowerKitten]] ([[User talk:PowerKitten|talk]]) 19:09, 9 October 2017 (CEST) | |||
:You should consider first the implications that this would have on Dolphin. As much as I like the function of this wiki as an archive, the first and most important goal should be making everything consistent with how Dolphin handles it. Right now, Dolphin gives all IDs as six character IDs. This is used not just for the right click wiki link function, but also is used on the game information display page in Dolphin, used in issue reports on the issue tracker, and used for Dolphin's GameINI system for automatically changing settings which cause issues (from reading {{PR|5763}}, that one ID you bring up only uses the extended format to avoid the automatic settings affecting other versions of the menu). If the standard was going to be changed in one place, it would follow that it should also be changed in the others. We're talking about multiple different codebases/databases full of the shorter format that would need to be changed. Not that it couldn't be done, there's people much smarter than me that could plan out and write programs to transition everything over, but I'm thinking about cost/benefit. In a perfect world, we'd just have a full archive of all GameCube IDs and Wii TMDs sitting on our laps and we could easily just swap everything over like it's nothing, but reality's not like that sadly. I'm not really sure how you plan to acquire these format of IDs for retail Wii games for example without actually buying the game, then dumping it, then looking for the TMD in the disc's filesystem, unless retail games' TMDs can also be accessed from Nintendo's servers? | |||
:Also, as far as I know there's never been any effort at all to document add-on DLC here, so there's no infrastructure or standards currently in place for that. If you wanted to make it, nobody's stopping you, but again, it should be framed in the perspective of how Dolphin handles DLC (which I have no knowledge about since I don't particularly like the Wii). - [[User:Xerxes|Xerxes]] ([[User talk:Xerxes|talk]]) 20:27, 9 October 2017 (CEST) | |||
::Fair enough, I'll go ahead and cancel this proposal. It wouldn't be worth the work involved. The other problem is with GameCube games, as their BNRs only use the ID6 format. Meanwhile, TMDs are a required part of how the Wii reads Wii games, so each partition of a Wii game disc has a TMD due to that. I'd have to buy and dump every Wii game to verify the full IDs, which would be a massive undertaking. Thanks for humoring me, Xerxes. - [[User:PowerKitten|PowerKitten]] ([[User talk:PowerKitten|talk]]) 16:13, 10 October 2017 (CEST) | |||
=== Gameplay Screenshots section worth staying? === | === Gameplay Screenshots section worth staying? === | ||
I think it'd be more appropriate to take them to HD screenshot thread in Dolphin forum. By getting rid of it from here, it'd be easier to distinguish between them and the emulation bug images here, because they wouldn't be anywhere here in the first place, and there are only few screenshots so it'd be much less of a loss compared to trying to get rid of gameplay videos. There seems not much going for HD gameplay screenshots here. There are lot of "Gameplay Screenshots" sections with nothing under that bothered me. I don't think anyone will care if it's gone along with those that contain screenshots. Do you agree? [[User:Lucario|Lucario]] ([[User talk:Lucario|talk]]) 23:59, 25 February 2017 (CET) | I think it'd be more appropriate to take them to HD screenshot thread in Dolphin forum. By getting rid of it from here, it'd be easier to distinguish between them and the emulation bug images here, because they wouldn't be anywhere here in the first place, and there are only few screenshots so it'd be much less of a loss compared to trying to get rid of gameplay videos. There seems not much going for HD gameplay screenshots here. There are lot of "Gameplay Screenshots" sections with nothing under that bothered me. I don't think anyone will care if it's gone along with those that contain screenshots. Do you agree? [[User:Lucario|Lucario]] ([[User talk:Lucario|talk]]) 23:59, 25 February 2017 (CET) | ||
:I'm fine with screenshots leaving! The wiki was never good at handling them. - [[User: | :I'm fine with screenshots leaving! The wiki was never good at handling them. - [[User:MayImilae|MayImilae]] ([[User talk:MayImilae|talk]]) 04:10, 26 February 2017 (CET) | ||
::Yeah, Wiki doesn't seem a good place for users' gameplay screenshots. [[User:Lucario|Lucario]] ([[User talk:Lucario|talk]]) 23:26, 1 March 2017 (CET) | ::Yeah, Wiki doesn't seem a good place for users' gameplay screenshots. [[User:Lucario|Lucario]] ([[User talk:Lucario|talk]]) 23:26, 1 March 2017 (CET) | ||
:Agreed that they haven't gotten enough attention to be worth preserving. [[User:Kolano|Kolano]] ([[User talk:Kolano|talk]]) 04:26, 26 February 2017 (CET) | :Agreed that they haven't gotten enough attention to be worth preserving. [[User:Kolano|Kolano]] ([[User talk:Kolano|talk]]) 04:26, 26 February 2017 (CET) | ||