Emulator

I'm not so sure if Registry is a good idea. Other applications use Environment variables or flat/empty marker files to do this.

I'd propose to ditch the two Registry ones and instead look for (example):

• Environment variable DOLPHIN_EMU_USER (pointing to a folder; should also work on *nix)

Flat file is more like portable.txt - as in, use the current program folder. Does not really make much sense to specify a different folder there, so I'd go with the environment variable.

We had the same discussion on #dolphin-dev with Neobrain, I'd also prefer environment variables but the consensus was that most applications do use the registry for that effect.

The "portable.txt" use case was something like "I use Dolphin on a USB drive on several different computers". This is solved easily with a command line argument + a .bat launcher/shortcut. I don't think we need it anymore.

The environment variable/registry use case is different. It's "I use several Dolphin versions on the same computer and I want all of them to use this configuration path / a local configuration)".

Environment variables can be set locally from a batch file, allowing us to switch from one user directory to the other. Registry can't do that (easily).

I'd dislike having to use batch files to startup Dolphin just because it's required to setup paths. Doesn't that make the cmd prompt show up, even if it's just for a few msecs? That looks unprofessional IMO.

Generally, it should be enough to somehow specify the location of Dolphin.ini. Everything else can be deduced from that file. I'd assume that we have 3 possible scenarios: a) People want to store stuff globally b) People want to store stuff per-build c) People want to have a stable build storing config globally, but also occasionally download development builds and want to have separate configuration for them. All three use cases are met with the original proposal of having a command line argument and looking for registry keys if the CL argument isn't specified. Like I said, I'd change the "UserConfigPath" string to point to the actual Dolphin.ini file, and parse all directory paths from that. Might as well move My Documents/User/Screenshots to MyDocuments/Screenshots while we're at it.

fwiw, about the general global user directory, I'd suggest the following:

• Cache, Config, GameConfig, Logs, Maps, OpenCL, Shaders, StateSaves in AppData: these folders shouldn't be touched directly by the users and/or should only be accessed via the Dolphin GUI.
• Dump, Load, ScreenShots, StateSaves: Should go to Documents.
• I'm not sure about GC, we have a memory manager GUI for that, don't we?
• I'm not sure about Wii, but I'm leaning towards AppData: The Wii folder structure is really confusing for users and we have a well-working Import/Export feature available in the GUI IIRC.

Code will have to be changed to support configurable directory paths anyway, so it shouldn't be hard to support this sort of "splitting".

I'm strongly against storing EVERYTHING in My Documents "for now" and changing it to use AppData after 4.0. This will break the updating process for 5.0 and/or require us to have some sort of config migration logic. Might as well do it properly now while we're at it.

Open question: No matter with which global user directory solution we go, we need to change something about our GUI to make sure people can actually figure out where e.g. texture dumps are saved. Also, global user directory means we have to print absolute file names, i.e. the "saved screenshot to XXX" OSD text might not fit into the render window anymore. Maybe it's not all that bad, but I guess we shouldn't forget about details like this.

To summarize my proposal:

• Locate Dolphin.ini
  • Look in the command line arguments for a flag that specifies the config filename (aka Dolphin.ini) (useful for Linux and OSX as well, fwiw).
  • Look in the registry for a boolean key "HKCU\Software\Dolphin Emulator\LocalConfigIni". If it's true, use User/Config/Dolphin.ini relative to the directory path Dolphin.exe is stored at.
  • Look in the registry for a string key "HKCU\Software\Dolphin Emulator\ConfigIniFilename" (using absolute paths). If it exists and points to a valid file, read the config from there.
  • Otherwise default to "AppData\Dolphin Emulator\Config\Dolphin.ini". (no User there; also note that I still dislike the "Dolphin Emulator" branding, but that's a different story; for consistency's sake I'd go with dolphin-emu like on linux instead, but I don't really care that much)
• Parse Dolphin.ini (or whatever the config file is called)
• Determine all remaining folder locations from fields in Dolphin.ini. An example ini section describing these locations would look like this:
  [Paths]
  Screenshots = "$USER/My Documents/Dolphin Emulator/Screenshots"
  Logs = "$USER/AppData/Dolphin Emulator/Logs"
  ...
• If these directories don't exist, mkdir them.

Just to ask the big question for the users: no one has been able to agree on this stuff, everyone has their own preference, and most don't like this plan (or any other plan...).

So, this will be user configurable... right?

+1 for pointing to Dolphin.ini, and loading everything else from there.
PJ64 for example seems to do something similar. At least they have config options for the most common directories (such as saves or screenshots).

As for the search order, I'd go for the other way round. Check AppData first, and when no config is found there, fall back to (the local config in User/Config/Dolphin.ini|some sensible default values) and store a new config in AppData when the user hits save.
The portable switch/file/whatever overrides this by always using User/Config/Dolphin.ini, while the other command line arg always uses the specified file.
In case you really want/need the registry one; just replace the AppData path with it and use that instead.

afaik pj64 uses the .rdb to save all the defualts and uses the .ini to override them

I won't be able to work on this until early/mid september, and this will probably require some testing before 4.0. I wouldn't feel comfortable merging that change in 10 days before a release.

RachelB, would you have time to work on this quickly (in the next 10-12 days)? You're a Windows user, unlike many of us :)

Global-user-config implements this as per delroth's initial post. Something needs to be done to copy the theme and game ini folders to the global directory though, and since File::CopyDir() isn't implemented for windows, and i find myself with zero interest in trying to figure out how to deal with the silly windows api, someone else will need to do that.

Issue 6565 has been merged into this issue.

Issue 6565 has been merged into this issue.

Issue 6565 has been merged into this issue.

Issue 6565 has been merged into this issue.

What's the status of this issue? Can anyone sum up the recent commits working towards a configurable user directory?

I think copying all default GameInis to the global user directory is wrong, for these reasons:

• it's confusing to have the same files at two places, especially when the first copy is basically just a backup.
• it's possibly making future changes more problematic than they need to be. E.g. having two types of GameInis (defaults and user-configured). Various usability problems arise here when the global user dir is full of default GameInis which should be empty actually.

For the second reason, I think implementing the two-types-of-gameinis idea should be blocking this issue.

If I have the time I'll try to get the following tasks done on the weekend:

• Display OSD messages for each GameIni override.
• Load read-only default GameInis from application folder (think of C:/Program Files/Dolphin Emulator/User/GameIni) and support loading user GameInis from the "writable" folder (think of C:/Users/User/AppData/Dolphin Emulator/GameIni). The latter overrides any settings specified in the former.
• Same for themes.

It works exactly the way delroth specified in the original post here in my branch currently. Nothing is done to handle themes or game inis.

Neobrain is going to work on Gameini overlaying today or tomorrow.

Game ini's should be implemented the same way on linux. Currently they are installed to a system location (/usr/share/dolphin-emu/user/GameConfig) and then copied to the users directory at run time.

I assume you probably know this already, and are planning on making things uniform across platforms, but I just wanted to make sure.

I did not mean to change the owner of this issue. It is complaining that NeoBranX is not a valid owner.

Yep, it's planned to be that way everywhere. Basically, by moving user directory to a global location, we should be able to merge all three platforms to the same User/Sys dir separation.

GameConfig are basically the only thing remaining here.

We are completely getting rid of the "global user" directory and keeping only this:

• Sys: read-only, present in EXE_DIR/Sys on Windows or PREFIX/share/dolphin-emu/data/sys on Linux or BUNDLE/.../Sys on OSX
• User: read-write, shared between all Dolphin versions, present in My Documents/Dolphin Emu on Windows, ~/.dolphin-emu on Linux, somewhere weird on OSX

So much improvement :)

s/somewhere weird/"~/Library/Application Support/Dolphin/"/

Moved Gameinis to Sys/ and completely removed all mentions of a shared user directory. That felt so good :)

Android is currently broken on global-user-directory because they do weird things with User/Sys/global User. Cc-ing sonic and lioncash.

Started working on gameinis overlaying. Currently, everything but Gecko/AR codes seems to be working. There are still a few TODOs/bugs:

• "Edit Config" buttons are broken/don't do anything/need to be implemented.
• When opening isoproperties for a game that doesn't have a global gameini, even without changing any setting values are written for PH/emulationstatus/emulationissues, which is undesirable (it should stay empty).
• The GameConfig directory needs to be renamed to something else (probably "GameSettings") for compatibility when migrating local user dir -> global user dir.
• Implement proper Gecko/AR loading, which is haaarrrddd and will require new INI sections specific to local gameinis, to track what codes are activated. This means a global gameini won't be able to enable a code by default, which seems desirable to me anyway.

Codes are even more a pain than I thought because they can be edited/removed from the GUI, and we obviously can't let users edit/remove stuff from the global gameinis.

Working on something that adds a metadata "user_defined" to patches/codes and disables edit/remove buttons on non user defined codes.

Code enabled/disabled status is stored in a special section called [_Enabled] (with being for example "OnFrame"). This section contains a list of verbatim/raw lines "$Name of the code". Sections like "OnFrame" don't use "+$Name of the code" to enable anymore.

Everything should be done now. Neobrain, care to review and see if I didn't miss anything?

Hmmm, more bugs than I expected. But first, the good news. Crude importing of gamesaves/configuration works great! Both Wii and GameCube games load perfectly. Everything works exactly as it should! Now for the bugs...

• The GameINI defaults in Sys/GameSettings are not read-only! I was able to click the "Show Defaults" button, change it to my liking, save the file, close it, and I clicked it again and it came back with the changes I put in. Uh oh.

• The local config is a little... odd. None of it is -wrong- per se, but from a user standpoint it is weird and performs a lot of unusual behaviors. I'll explain. If I hit "Edit Config", create a new file when prompted, leave it blank, then save it and close it, when I hit "Edit Config" again it will ask for a new file again when I click it again. If I say no, it deletes the file, if I say yes, it creates one. That look will continue forever. If I put random stuff into the file it will delete it still, as if it was empty. Alright. Copy paste the stuff from the default into it and it will keep, but it will delete everything and restructure it all.

None of these behaviors are wrong, it's just... weird. Very counter intuitive. Most people would expect that if they create a file it will stay there. Or if they put something into a file and save it that will stay there. Or they'd expect that if they copy paste the defaults into the file they might as well edit it then, since saving and bringing it back would normally not change the file.

I'd suggest... when the emulator asks "Do you want to create a file" and they say yes, that it automatically fills out all of the defaults (minus AR codes and things) and then the notepad appears with that in it. That one change would avoid all of these problems in one swift stroke. Of course, that's assuming you can do that...

• Minor annoyance: When I press "Show Defaults", look at the notepad that comes up, then close the notepad for the ini, Windows puts windows explorer as the focus in front of Dolphin. No matter where the window is it makes it the focus when closing that Notepad file. Dolphin never used to do this, and hitting "Edit Config" doesn't do it... It's weird to be sure. And since I don't use shortcuts for Dolphin, there's always an explorer window right behind it. >_<

• Deleting a GameINI from the user game settings doesn't get rid of it! The emulator brings it right back the next time you click edit config. Granted it resets it to default so, again, nothing wrong with it, just... odd for a user. Just pointing it out.

Point 1, 3 and 4 are definitely valid. 1 is a bit complicated to fix, but the worst thing that can happen from this is people modifying files that will be overwritten when they upgrade Dolphin. Not really a problem: they edited stuff that was marked as "defaults", I guess they got what they should expect. I'll try to fix it anyway. 3 is me forgetting a line of code, and 4 is just a bug, I'll fix both quickly.

2 is just a consequence of how local gameinis work now: they only contain the overrides. If something is not an override, it is not saved. If it does not contain any override (f.e. it contains exactly the same things as the global gameini), it will just be deleted because it is useless. I know this behavior is debatable but it is the only one where we could think of a proper implementation. I know it's "weird", but all in all it makes sense. It's just a bit different. Not planning to fix it, or maybe post-4.0.

Kostamarino also reported an issue with gameinis not having Windows line ending on Windows, I guess that could be fixed with git properties. I'll have a look.

I can't reproduce your fourth issue (local gameini coming back after being deleted). Can you provide me with the global/local gameinis that cause this problem?

Merged to master, I'll let this open for a few days until we get more feedback on bugs and stuff.

I have Two different Dolphin Folders with the emulator in them, because with one video plugin certain games play great but with the other plugins they run like crap. So would like to play with certain plugin staying the same.

I have mamewah frontend that I run these through. So when I put in the video plugin that I would like for one the other one in the other folder changes to that one also.

I'v tried the registry edit, but it only recognizes "Dolphine Emulator" If I try to edit for another folder, it will not recognize. Anyone have any good ideal on how to keep the two separate. So I can run two different ones with to different video and audio config.

This is not a support forum. Fortunately we have one. - https://forums.dolphin-emu.org

That is why we game game specific config.