Input and Output of the Patcher #9

New issue

Open

opened 2024-08-27 14:01:10 +02:00 by faraphel · 0 comments

faraphel commented

2024-08-27 14:01:10 +02:00

Owner

Input and Output of the Patcher

The patcher is responsible for applying modifications on a given file, and send back another patched file.

This require a mechanism to insert a file into the virtual file system of the patcher, and another to retrieve the output.

This can be done in multiple way, but we still need to consider multiple things :

the process of starting the patcher should be as single as possible for the user, this imply only giving the base game file, changing the settings of the installation, and pressing a start button.
the result of the patcher should be safe : if we gave a Wii game image to patch, we are expecting another Wii game image on the other end, not an executable.
The developer should have a way to mark the output of the application among all the generated files. It may be by putting in in an output directory, or using a function given by the engine to set the output files.

To do so, the patch meta informations shall contains a "type" indicating which files he is looking for in the input, and which files is he supposed to receive in the end. For example, a type "Wii Games Patch" would indicate that the patcher is expecting an iso, wbfs, etc. and expecting a file of the same kind in the output.

A function atlas::patch::setOutput(Path@ path) might allow the developper to set the output file. Note that if the patcher is expected to return multiple files, either because it use another type that would return more differents files, setting others output files might be necessary, either by selecting an entire directory, or mapping files to a dictionary of output path.

# Input and Output of the Patcher The patcher is responsible for applying modifications on a given file, and send back another patched file. This require a mechanism to insert a file into the virtual file system of the patcher, and another to retrieve the output. This can be done in multiple way, but we still need to consider multiple things : - the process of starting the patcher should be as single as possible for the user, this imply only giving the base game file, changing the settings of the installation, and pressing a start button. - the result of the patcher should be safe : if we gave a Wii game image to patch, we are expecting another Wii game image on the other end, not an executable. - The developer should have a way to mark the output of the application among all the generated files. It may be by putting in in an output directory, or using a function given by the engine to set the output files. To do so, the patch meta informations shall contains a "type" indicating which files he is looking for in the input, and which files is he supposed to receive in the end. For example, a type "Wii Games Patch" would indicate that the patcher is expecting an `iso`, `wbfs`, etc. and expecting a file of the same kind in the output. A function `atlas::patch::setOutput(Path@ path)` might allow the developper to set the output file. Note that if the patcher is expected to return multiple files, either because it use another type that would return more differents files, setting others output files might be necessary, either by selecting an entire directory, or mapping files to a dictionary of output path.