(11-11-2015, 06:46 AM)Kolano Wrote: [ -> ]If a game needs EFB2RAM be enabled and such is not pre-set by it's ini file, wouldn't we want a report on that so appropriate edits can be made to the games ini?
Indeed, but not if it's in the game INI already, and not if it only is required for certain minor things like the ones listed on the SSBB page.
(11-11-2015, 06:46 AM)Kolano Wrote: [ -> ]There are a limited subset of problems on the Wiki we wouldn't want issue reports for, for instance bugs in games themselves that also occur on real hardware. We tend to list such on the wiki to avoid erroneous future reporting. We've recently started to transition those sorts of problems to a separate section from Problems, which should allow us to distinguish them and avoid encouraging issue creation for them.
Sounds good to me.
(11-11-2015, 07:21 AM)JosJuice Wrote: [ -> ]That would be nice, but computers are not magic. Some games simply require things like EFB2RAM, period. It can't be fixed (other than getting rid of the more inaccurate options).
Fair enough.
(11-11-2015, 07:21 AM)JosJuice Wrote: [ -> ]Yes, there are some EFB2Texture issues that are valid on the bug tracker, like the fix for palettes. Most aren't. I am not going to support the bug tracker being full of useless reports for the sake of possibly catching some rare valid issue that looks identical to the useless reports. Telling them apart requires debugging the game and knowing if Dolphin is doing something wrong, and I don't think any developer is going to bother doing that for a significant amount of issues that are likely to be irrelevant.
As Kolano mentioned, I consider this a *.ini request change for all future distributions of Dolphin if the problem can't be fixed through code.
(11-11-2015, 07:21 AM)JosJuice Wrote: [ -> ]Okay. What does that have to do with anything?
It has an associated bug report. It acts as a reminder that Dolphin needs code to emulate that feature some day. It's not really a bug report but the benefits of the report are there.
(11-11-2015, 07:21 AM)JosJuice Wrote: [ -> ]So you want to provide a good overview of how seriously different settings affect the game, but the overview mentions nothing at all about which settings affect which issue?
You raise a good point there. I didn't think of that. That would require templates for each setting and have that template be called with my RatingProblemFix template. The templates would be a waste though but they could be repurposed for the config template to make them less of a waste.
https://wiki.dolphin-emu.org/index.php?title=Template:Config
(11-11-2015, 07:21 AM)JosJuice Wrote: [ -> ]That's nice, but it doesn't get rid of the need to actually do work, and there's still the problem that the templates will make things harder for first-time editors. It could be worth it if the system has enough advantages, but I don't think it does.
Every Wiki needs work. At least my template wouldn't put the pressure on only the people that already know the articles are out-of-date. It brings the attention to the probably uninformed reader as well. It gives the work that needs to get done some direction.
(11-11-2015, 07:21 AM)JosJuice Wrote: [ -> ]I guess putting pages that lack bug report links or issue ratings in special categories might help with fixing the lack of bug report links and issue ratings, but in what way does that improve the wiki? The real problem is many games lack issues or have outdated issue descriptions, which only can be fixed by people actually going out of their way to test games and write about issues. If you want to have a template like on https://wiki.dolphin-emu.org/index.php?title=Schlag_den_Raab/sandbox that says "this is out of date" and puts the page in a category of outdated pages, then I guess that's cool. What I don't see the point of is the issue ratings.
The end goal I have with issue ratings is that it performs a multitude of useful functions just with the use of one template alone.
(11-11-2015, 07:48 AM)wildgoosespeeder Wrote: [ -> ]As Kolano mentioned, I consider this a *.ini request change for all future distributions of Dolphin if the problem can't be fixed through code.
We will happily accept reports about INIs lacking necessary settings, but like I said to Kolano, we are not going to set slower settings in INIs if only small parts of a game require it. It would have too much of an effect on the performance.
The number of issues that cannot have valid issue reports is probably smaller than I originally thought, but the way the SSBB example page looks right now, the problem still exists.
(11-11-2015, 07:48 AM)wildgoosespeeder Wrote: [ -> ]It has an associated bug report. It acts as a reminder that Dolphin needs code to emulate that feature some day. It's not really a bug report but the benefits of the report are there.
Yes, the issue tracker is for feature requests too, not just bug reports. That doesn't mean that we will accept impossible requests.
(11-11-2015, 08:01 AM)JosJuice Wrote: [ -> ]We will happily accept reports about INIs lacking necessary settings, but like I said to Kolano, we are not going to set slower settings in INIs if only small parts of a game require it. It would have too much of an effect on the performance.
The number of issues that cannot have valid issue reports is probably smaller than I originally thought, but the way the SSBB example page looks right now, the problem still exists.
I find that a simple setting to enable the use of *.ini can solve this problem. The recommended setting is
on. Just like the
FPRF or
Syncronize GPU Thread settings (required for F-Zero GX), you could tell each game to disable the use of *.ini specifically.
(11-11-2015, 08:01 AM)JosJuice Wrote: [ -> ]Yes, the issue tracker is for feature requests too, not just bug reports. That doesn't mean that we will accept impossible requests.
That didn't stop Famicom Disk System emulation support for Nestopia or FCEUX. I'm sure that support was an idea but wasn't implemented yet until most or all NES games would emulate without issue.
(11-11-2015, 08:57 AM)wildgoosespeeder Wrote: [ -> ]I find that a simple setting to enable the use of *.ini can solve this problem. The recommended setting is on. Just like the FPRF or Syncronize GPU Thread settings (required for F-Zero GX), you could tell each game to disable the use of *.ini specifically.
I'd rather have specific INI settings that can be toggled on and off, because some games both have settings that are absolutely required and settings that only are needed sometimes. It sounds like a nice idea in general though, so feel free submit it as a request on the issue tracker if you want to. I don't think we have a report like it already.
(11-11-2015, 08:57 AM)wildgoosespeeder Wrote: [ -> ]That didn't stop Famicom Disk System emulation support for Nestopia or FCEUX. I'm sure that support was an idea but wasn't implemented yet until most or all NES games would emulate without issue.
I'm not saying the Game Boy Player issue is invalid, I'm saying issues about things not working in EFB2Texture (generally) are invalid. I agree with the Game Boy Player issue's current status in the issue tracker. (Implementing the Game Boy Player hardware is like implementing the Famicom Disk System, by the way. The former essentially requires an entire built-in GBA emulator in Dolphin.)
I've wanted to close this from day one, but being a wiki admin I kept my distance. The fact is, conversation about how the wiki is run should be held on the wiki itself, among those that contribute to it. Especially when its in the case of vast changes like this! Its fine to talk about the wiki on the forum in a limited fashion, but this goes far beyond that. In the future, any such threads like this I will close immediately, as I should have with this one.
*closed*