rafalh
Add an option to force mods to use the base players.cfg file
Currently, Red Faction creates a new .cfg in the directory for each mod if it does not already exist. I usually duplicate players.cfg to maintain the same settings as the base game for each mod, and this practice works fine when I have just a few mods installed. However, this becomes cumbersome when there are about eight or more .cfg files to replace each time I want to switch up my controls, audio, difficulty, etc.
I suggest that Dash adds a launcher option (and perhaps a console command) to skip the creation of separate .cfg files for mods and instead use players.cfg, unless one already exists for the mod. That way, settings from the base game can easily persist for use in mods, and the game directory will not be flooded with potential duplicates. At the same time, mods can still use separate .cfg files if needed.
I wonder why it creates separate cfg files for mods... What was the reasoning behind it :thinking: If anybody knows let me know. I was testing a mod today and (as I rarely run mods) I was surprised that my normal key binds don't work. I think an option to disable this behavior is a good idea. Or perhaps if there is no benefit in having multiple cfg files current behavior could be changed without an option to bring back original behavior. This would be preferable to avoid unnecessary code complexity.
I wouldn’t mind the current behavior being changed without a toggle. But I can see how having separate cfgs can be useful for some mods. For example, the Lego multiplayer mod changes the player models, and it may be a bit jarring re-entering the main game and having to change the selected model back for the original set. Maybe a button could be added next to the mod selection in the Dash launcher that creates a new separate cfg for the selected mod to cover cases like those.
If an option were to exist to disable this functionality (ie. force using the default players.cfg file when loading mods), it would have to be done very carefully. Mods that change the IDs for MP player characters or number of usable player weapons would almost definitely be problematic. To illustrate, I ran a test - my LEGO_MP22 project (unreleased) only has 7 player weapons (compared to the base game's 15). When I copied my stock game players.cfg and renamed to players_LEGO_MP22.cfg and launched the game, the controls section of the options panel displayed some "phantom" weapons with corresponding keybinds:
I also recall from memory, when I was first working on LEGO_MP22 I had copied my base game players.cfg to use, and my MP character select screen displayed some random texture rather than the correct character portrait - I'm guessing because the pc_multi.tbl in LEGO_MP22 doesn't use the same class names as the stock game.
Generally an option to disable a mod using a separate players.cfg would be safe from what I know when it comes to mods that don't change either of those things, but I don't know for sure that there aren't other scenarios where it would be problematic.
"Or perhaps if there is no benefit in having multiple cfg files current behavior could be changed without an option to bring back original behavior." If it were to be implemented, it would only be acceptable in my opinion to have it as a choice rather than forcing the change. Aside from potential issues that may come up, it'd be fairly normal for people to want to set different weapon switch binds in ISM vs the stock game, for example. Removing that capability would definitely be a regression.
In an ideal scenario, I think this should be another item that mod developers could specify in the dashoptions.tbl file to be included in a vpp in the TC mod directory (as referenced in issue #173 ). Perhaps an option like "$DF Use New Players Config: false" could be read from this file, and allow the mod developer to decide whether their TC mod should have a new players.cfg file separate from the one used for the base game (defaulting to the stock game's behaviour if not specified). At that point, it'd be up to the mod developer to make the decision based on whether their mod requires a players.cfg file separate from the base game or not - I think that would be the proper way to go about making this change.
I didn't think about weapon mods, you are right Goober. I have one more idea. Dash could detect if mod changes weapons.tbl or pc_multi.tbl files and create a separate config file only if those files are modded. I wonder if there are many mods that do not modify those files.
Dash could detect if mod changes weapons.tbl or pc_multi.tbl files and create a separate config file only if those files are modded.
I think this is a better idea than changing the behaviour outright, but I still strongly think that my suggestion of having it as a configurable option exposed to mod developers would be the best and safest way to make the change. The author of a mod really is the correct person to make the decision on what their mod needs to work properly, I think, not us or the player.
I wonder if there are many mods that do not modify those files.
I doubt there are very many - the weapon table is probably the most common table to be edited in mods, and typically if table files don't have to be edited, the author is just going to release their work as a clientside mod or map for the stock game rather than as a TC mod.
The Lego singleplayer mod has a modified weapons table and it works with no issues when players.cfg is copied over. There appears to be no straightforward way to tell how this will affect various mods with custom tables. Goober's suggestion to implement this as an advanced option for developers is a scalable one and would ensure that compatibility is not broken with existing mods. Players could manually apply this to existing mods that are compatible with the base players.cfg.