Mod (Modifications) Support

[LukasThyWalls]

Hello.

Maybe can you ponder a, on paper, simply idea to make some modifications support to ScummVM, mainly to make some things with the application simplier in the normal usage. It could be a QSoC entry or something like that, if in the end you are interested.

Why

The main reason for this in my usage is about translations: I'm spanish and a lot of games have fan translations, mainly because they never were done officialy in my language. However, i normally have two folders for each of those games, one in the original form (English) and other with the game with the patched files to make it in Spanish. So, in the GUI, i have some (in fact a lot) of repeated listed games, in English and Spanish. But also can work for other things, for example, i have Police Quest 2 three times: One in English, other with the fan translation to Spanish, and other with some files that change the game to have the Japanese graphics. In this case, the point is instead of three entries, have only one in the ScummVM GUI.

That also means one set of options for each game, instead of two or three, a save spacing of don't have games repeated with minimal changes, and also a unique set of save games for a game with a set of mods instead of a few of sets, although that need to be looked if it can be an issue or not.

The Idea

The idea came when seeing the mods support in System Shock: Enhanced Edition:
​https://imgur.com/ctPtgkO

Something like that could be done for each game in the ScummVM GUI: A new tab, with showing a list of mods, ability to change the order or them, and some way to activate and deactivate them.

In ScummVM.ini, it could be a new string for every game entry called "Mods", and a list of the mods activated in an order.

The mods themselves could be in a folder inside the game folder called "Mods", "_Mods", "ScummVM-Mods", anything that doesn't interfere with any game, and inside that folder, a folder for every mod (that could be the names used in ScummVM.ini), and all of the are the list in the ScummVM GUI. As an upgrade to this, it could be included a Mods.ini in the Mods or the Mod folder to add better name and description to the ScummVM GUI.

Inside those folders, the files are only the changed files from the originals, so when it loads a game (with A, B, C files) and there is a mod activated with some files (B*, D*), the game will run with the mix from both (A, B*, C, D*). Here also comes, if there are multiple mods, a priority between them, so the same files from the higher priority mods go over the lower priority ones.

Issues

Thinking about this, the main concern is how ScummVM can do that "virtual game folder" mixing files from different folders in runtime which is the trick that make all of this working.

About the savegames, talked above, i suppose that depends from the engine and the save system, maybe saves made with a mod, when you disable it (and viceversa), the saves could still work or not. Some tests i did with AGI/SCI games are they still works, but maybe in some case they don't and other games would not work, so the people with more knowledge about that can said something against all of this.

About detecting the games, ScummVM can still detect the games modded (As a lot of them are detected by default), but with the mods, ScummVM could not detect them, only the base game is detected and the mods should be compatible with that engine. If something doesn't work or the game crash with mods activated, ScummVM could ask to deactivate them first and try again, also can be a warning in the ScummVM GUI tab for Mods.
This also opens for modifications that can be added without being added to the ScummVM detection, simplifying that task for the future.

As said, for errors, the first point to test why a game doesn't work is to deactivate separately or all mods and try again, and later add the full modded game to ScummVM and look if it works. If it still doesn't work, it's a mod issue, maybe because is not compatible with ScummVM or because the game modded itself doesn't work, and then it will be a separted issue.

Thanks.

[sev-]

Unfortunately, this cannot work as a generic solution and must be implemented per-engine. We have over a hundred engines now and some already support this functionality.

Thank you for your detailed description.