Custom configuration for each game #632
1 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: MeloNX/Ryujinx-ryubing#632
Loading…
x
Reference in New Issue
Block a user
No description provided.
Delete Branch "master"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Now you can make a separate configuration (independent file) for each game. All emulator settings are available except for control. The configuration file can be changed and deleted from a separate menu. The user configuration menu is available through the context menu
Pull request is in beta. may require revision
These needs to be reverted
huh?
Needs a locale key
Locale key
Yes, I forgot about that. sorry.
Download the artifacts for this pull request:
Only for Developers
Gamepad settings added for user config
could the game title be added to the settings window title if it's a game specific configuration?
e.g.
Ryujinx 1.2.x - Settings - The Legend of Zelda: Tears of the KingdomYes, no problem.
just for your information the bot message with builds auto-updates with new builds after all checks have completed :-)
you do not need to provide your own builds.
I didn't know, thanks for the information.
IMO per-game config should be a separate config object with an Nth value for settings and/or categories of "inherit system settings". That will make it clear in the UI which settings will be changed when you update the main settings vs. which ones you have configured for that specific game.
The current implementation is made for compatibility, otherwise it would be necessary to rewrite even more code. This could break existing configurations or bring even more bugs. Although I do not deny that it was possible to work in this direction.
This is looking really good! Looking forward to it.
What's the point of this?
Remove this, this should be already done by the
SettingsViewModel(bool)constructor this one calls up to viathis(...).Please rename this class without the plural, and something more descriptive.
I think
GameSpecificSettingsWindowfits.It includes the name
SettingsWindow, so you know it's for emulator settings like the regular window class namedSettingsWindow.Rename to
HasIndependentConfiguration@ -15,3 +19,4 @@public static string OverrideSystemLanguage { get; private set; }public static string OverrideHideCursor { get; private set; }public static string BaseDirPathArg { get; private set; }public static FilePath FirmwareToInstallPathArg { get; set; }Leftover from a previous implementation?
string titleId = ""bool shouldLoadFromFile = trueI guess I just didn't fully understand what it does. I decided that it's the same as this.
`
// Check if memoryManagerMode was overridden.
`
At this stage, this pull request is working, if you run future builds without this function, then other builds do not crash, that is, emulator builds are compatible with each other
Loading and saving the game with and without a custom configuration have been tested.
The functions of saving, changing and deleting a custom configuration do not affect the global config in any way.
Some settings from the global configuration will not work for the custom configuration (in particular, functions from the user interface, theme, game directory, etc. for obvious reasons).
The emulator will automatically restart with the selected game when using the custom configurator, if the "graphics multithread" setting has been changed and differs from the global one.
The custom setting can be removed from the "Edit Game Configuration" context menu before loading the game.
Correct if I'm wrong, are we always saving the whole config for per game - meaning changing one entry into per game would result in all the other entries unable to update following the global changes?
Yes, that's exactly how it works, absolutely the entire configuration is saved, even if one value was changed. This is how it works in the original, this is how it works for a separate configuration. If you need it to work differently, you need to rewrite the save system and do additional checks for the original ryuujinx.
To simplify, the global configuration is also saved in a custom setting, but it will never be used, because some of the settings will not be rewritten upon loading. which settings exactly will not be rewritten are set in the ConfigurationState.Migration.cs configuration file
If you need the settings to be taken from the global configuration, just delete the custom configuration file and create it again
Thanks for the reply! It feels a bit costly to use the per game settings in that way. Indeed to avoid that the saving mechanism may need to be rewritten, so I'm just sharing my thoughts here.
If we want to implement that, on saving we can compare the game settings with the global one and skip all identical entries, so only the difference is saved. On loading we always load the global config first then update fields with entries existing in the game config.
Yes, I was adjusting the code in the process and at one point I made it so that the setting would only load once, but then I came to the conclusion that it is better to reload the settings twice so that the global configuration would also load. This solved the problem with updating the settings.
I do not argue, the current implementation is resource-intensive, but this only happens when loading the user configuration, and only at the moment of initializing the settings or saving them. In addition, not all games need user configurations.
But this solves the main problem, you do not need to go into the configuration file every time if one or two games ask for special settings for it to work
Yeah I agree, overall it would work well and I quite like this change. The improvement can be saved for the future once we get a chance for it 😊
I don't know for sure, but maybe there are reasons why it is not merged with the general branch. Maybe it needs thorough testing.
Although I wanted "software maintenance" after merging the pull request to be possible without my participation. I will still try to fix bugs if they appear concerning this function.
All problems that arose during the process of adding this function have already been solved.
I personally have some more feedback, but I've been too busy to do a more in-depth check of the code.
I'll try to get it written up this weekend if I have time :)
This doesn't work because the user might affirmatively want a per-game setting that's presently the same as a global setting, but may want to change the global setting in the future without changing the per-game setting.
There is no unambiguous way to imply when you want the per-game setting to follow the system setting. It needs to be explicit. So, to make this sort of thing work, we'd need one of the choices for each per-game setting to be something like "follow global setting." Explicitly save "follow global setting" to the per-game config file. Then, when loading, load the global config first, then load the per-game config, skipping items in the per-game config that say "follow global setting" while clobbering everything else.
This is a feature of the function, when creating a custom setting, you create your custom configuration based on the current global configuration and untie from the global except for a few settings. At the moment, this is how it works.
Other implementations require rewriting the save system and rewriting the entire settings menu. This may break compatibility with the current implementation.
Do you have special scenarios in which some setting of the global configuration needs to be applied to user configurations?
user settings are needed mostly for problematic games, other games if they launch and play well, there is no point in configuring them individually
I would favor merging this commit with the current implementation -- the per-game config is a complete config, with no falling back to the global config. Occasionally having to manually change multiple per-game configs is a hassle, but not a huge one.
I was just pointing out that the floated idea for how to potentially implement falling back to the global config by omitting unchanged elements from the per-game config wouldn't work. When the user leaves a value unchanged, it's ambiguous whether the user means "follow the global config" or "I affirmatively want the same value that the global config has right now." If you want to go down the path of having a way to fall back to the global config, then "follow the global config for this setting" needs to be explicitly saved to the per-game config. But you don't seem inclined to go down that path right now, and I don't think you need to.
I understand you. I am very sorry that this innovation does not work as you want at the moment. But the original implementation requires radical changes in order to do exactly as you want.
Here you have correctly noted that this innovation has a fundamentally different approach (it was chosen for a reason). First of all, to maintain compatibility with the old implementation of saving and loading the configuration. You can safely run another version of the emulator without this function and the emulator will load without errors
The original code was simply not designed for user configurations.
i tested in a few games and works perfects!
any idea when this will be on canary version?
This is a rebooter, not an updater; the update stuff should probably get removed(?)
There is no need to delete it. At least I made it so that it works in this code
It reboots the emulator if the graphics stream for running the game in the user configuration differs from the one loaded when the emulator starts.
I just decided not to rework the updater class, but to make a new class for rebooting