Not sure if this particularly has been suggested before but I think it may be a somewhat novel solution to the ongoing debate over engine defaults and standalone games.
Short version:
Allow per-IWAD INI files, with the option for mods to prefill certain defaults.
Long version:
In a custom lump (?), the modder will define a default .ini file. This could be as simple as copy-pasting their own tuned ini file into the lump.
When the IWAD is loaded, the presence of this lump prompts GZDoom to search for an appropriate config file, such as
gzdoom-iwadname-username.ini, and use it as the running config.
If this file does not exist, a new config file with the same appropriate name is created. This config is pre-filled with the defaults from the IWAD's .ini definition,
WITH THE EXCEPTION OF CERTAIN BLACKLISTED CVARS such as screen resolution, renderer, etc. If these engine-blacklisted settings exist in the custom ini, a warning is generated and the value is not parsed. The blacklisted values could be taken from the user's existing ini file or regenerated from standard engine defaults.
Rationale:
Currently the only sane way for creators to provide default settings is to ship a custom ini as a separate file, or a whole GZDoom installation. I feel like this provides a soft-override which is important for modders who are shipping TCs, custom IWADs, standalone games, etc, but still want to use the stock compiled engine for convenience (for example if GZDoom is installed system-wide instead of in a portable folder). If a user is unhappy with the shipped defaults, they can still change them as normal, copy-paste their own (untouched) .ini into the new one, or delete the defaults lump.
Problems:
Allowing custom configuration per mod will likely lead to a lot of modders jumping on the opportunity to force their preferred defaults. To this end I think such a feature should be limited to custom IWADs and IPK3s as the use case is more specific and the barrier to creation is slightly higher.
File count bloat may be an issue, as a new config would be created for each mod that includes default definitions. An alternative implementation would be mod namespaces in the main config file, which has been suggested in other contexts but never implemented. Separate config files seems to be the more robust option as they can be easily deleted wholesale, whereas namespaces in the main config would require quite a bit more work to remove bloat.
I see user confusion as the main objection to this kind of feature. I propose that a popup window could be used to alert the user that the mod is requesting to provide custom config settings, whenever a new config file is created (this would be suppressed if the config already exists or the user opts out of the alert, much like the IWAD selector).
I anticipate a major point of debate would be what settings to blacklist. In my opinion, blacklisting too many things in the name of user-choice defeats the purpose of this feature. Hence, my opinion leans toward a minimal blacklist of critical settings such as display resolution, audio devices, renderer, etc. That said, I think having the ability for standalone IWADs to define defaults is better than
not having this ability, so some level of compromise is certainly not out of the question.
Discussion appreciated!
Not sure if this particularly has been suggested before but I think it may be a somewhat novel solution to the ongoing debate over engine defaults and standalone games.
[u][b]Short version:[/b][/u]
Allow per-IWAD INI files, with the option for mods to prefill certain defaults.
[u][b]Long version:[/b][/u]
In a custom lump (?), the modder will define a default .ini file. This could be as simple as copy-pasting their own tuned ini file into the lump.
When the IWAD is loaded, the presence of this lump prompts GZDoom to search for an appropriate config file, such as [b]gzdoom-iwadname-username.ini[/b], and use it as the running config.
If this file does not exist, a new config file with the same appropriate name is created. This config is pre-filled with the defaults from the IWAD's .ini definition, [i]WITH THE EXCEPTION OF CERTAIN BLACKLISTED CVARS[/i] such as screen resolution, renderer, etc. If these engine-blacklisted settings exist in the custom ini, a warning is generated and the value is not parsed. The blacklisted values could be taken from the user's existing ini file or regenerated from standard engine defaults.
[u][b]Rationale:[/b][/u]
Currently the only sane way for creators to provide default settings is to ship a custom ini as a separate file, or a whole GZDoom installation. I feel like this provides a soft-override which is important for modders who are shipping TCs, custom IWADs, standalone games, etc, but still want to use the stock compiled engine for convenience (for example if GZDoom is installed system-wide instead of in a portable folder). If a user is unhappy with the shipped defaults, they can still change them as normal, copy-paste their own (untouched) .ini into the new one, or delete the defaults lump.
[u][b]Problems:[/b][/u]
Allowing custom configuration per mod will likely lead to a lot of modders jumping on the opportunity to force their preferred defaults. To this end I think such a feature should be limited to custom IWADs and IPK3s as the use case is more specific and the barrier to creation is slightly higher.
File count bloat may be an issue, as a new config would be created for each mod that includes default definitions. An alternative implementation would be mod namespaces in the main config file, which has been suggested in other contexts but never implemented. Separate config files seems to be the more robust option as they can be easily deleted wholesale, whereas namespaces in the main config would require quite a bit more work to remove bloat.
I see user confusion as the main objection to this kind of feature. I propose that a popup window could be used to alert the user that the mod is requesting to provide custom config settings, whenever a new config file is created (this would be suppressed if the config already exists or the user opts out of the alert, much like the IWAD selector).
I anticipate a major point of debate would be what settings to blacklist. In my opinion, blacklisting too many things in the name of user-choice defeats the purpose of this feature. Hence, my opinion leans toward a minimal blacklist of critical settings such as display resolution, audio devices, renderer, etc. That said, I think having the ability for standalone IWADs to define defaults is better than [i]not[/i] having this ability, so some level of compromise is certainly not out of the question.
Discussion appreciated!
8-)