Project

General

Profile

Actions

Emulator Issues #8975

closed

Lock Essential Settings through INIs

Added by JMC4789 over 8 years ago. Updated over 6 years ago.

Status:
Fixed
Priority:
Normal
Assignee:
-
% Done:

0%

Operating system:
N/A
Issue type:
Feature request
Milestone:
Regression:
No
Relates to usability:
Yes
Relates to performance:
No
Easy:
No
Relates to maintainability:
No
Regression start:
Fixed in:

Description

Users can't be trusted, therefore we need to help them out sometimes. I propose that we make immutable game settings for games where they are unplayable without X settings. Yes, it will be a judgment call, yes, it'll probably piss off some people. But, at this point, I've been watching my cousins play Dolphin, and it's very, very apparent that we suffer badly with usability issues. They don't know what any of the stuff in the UI means, they don't know what settings do what, we need to make things as easy as possible.

So, we need a second class of "forced" settings in the INI files that basically "lock" a setting in the UI. Opening the graphics menu WON'T override it, rather, the user won't get the option to break it. This is useful because my cousins would have the correct setting, and then change it to the wrong setting because "it's faster" and not realize what broke the game until later.

Here's an example of one I'd force on: Super Mario Sunshine - EFB2RAM + Safe Texture Cache. The game just isn't playable without these settings.

Example of a game where I WOULDN'T force it on: The Legend of Zelda: The Wind Waker - EFB2RAM. It's only needed for a subquest where turning it on for that point is plausible.

What does everyone think? I know it'd be a lot of work to setup at first, but, I think in the long run having immutable settings could be useful.

Actions #1

Updated by JosJuice over 8 years ago

I don't want any settings that are completely immutable, because users who are certain they want to change the settings would edit the default INIs to get what they want, even though those INIs aren't supposed to be edited. A way to make settings hard to change but not impossible sounds good, but I suppose it will have to wait until the config system is redone.

Actions #2

Updated by MayImilae over 8 years ago

I completely, totally, and utterly disagree with this idea. The problem is that opening the graphics configuration window resets the settings without alerting the user to it first, so they can go to say, change their resolution, and break a setting without realizing it. The solution to this problem is proper UX that alerts them before the change. In essence, this idea is trying to force users to use specific settings because our GUI is bad at communicating to them. That is not how you do things!

Actions #3

Updated by TheDimensioner over 8 years ago

I think I can give my user opinion here. It took me a long time to figure out what INIs were for, but now I kind of use them all the time to add or remove things, that although it would "break" a game, it would still be playable at some areas, and there's always the wiki with helpful information regarding problems. I know the wiki is not up-to-date in real time with the dev build releases that might fix things, but still, since I have a poor system, it's at least good to know the games I can have at least a try.

Using Super Mario Sunshine as an example, even though EFB2RAM is necessary to clean the goo stuff, not all levels have the goo, so I can use a hotkey to enable it when needed (since I already had it disabled in the INI). It'll work like it should, I would just have to decrease the internal res to cope with the slowdown. Another option is the "PerfQueries" thing that it's to fix the level that wasn't clearable before, but the option slows down the whole game. Since it's only one level (it's said to be, don't know about others), I simply have it disabled on the INI, and when I get there, I'll enable it and clear it. It might be strange to live with this balance between quality vs playability, but I love Dolphin because it allows me to it.

Locking those options, simply would make them not be options anymore, so, I'm against it.

Actions #4

Updated by ghost over 8 years ago

I think that instead of locking settings you should provide a way to restore them. Like "default" button, that restore all (or only important) settings to per-game defaults.

Actions #5

Updated by kostamarino over 8 years ago

I wouldn't be against them not to change when you open the graphic settings window if there is any good solution suggested about it if you want to be able to change settings on the fly at the same time. For example you could blacken out all options when opening the window while the emulatior is running, but then again you wouldn't be able to change them on the fly. If any dev has a way to circuvent this issue i am all for it.

Actions #6

Updated by JMC4789 over 6 years ago

  • Status changed from New to Fixed

We now do not screw this up as bad in the UI. I'm considering it fixed. Settings now show up as what Dolphin overrode them, and users are forced to override them themselves.

Actions

Also available in: Atom PDF