Make Portable

[jet082]

Currently, this patcher is heavily tied to the interface that you see publicly in the demo. So much so that it even calls specific DOM elements by id in the main patcher js.

It would be nice to separate the logic of the actual patcher itself from the GUI elements so that it can be easily imported and used on other websites and not, very specifically, the one provided.

Additionally, the patcher seems to require a very specific structure, with a js folder at root, etc. Quite a few of the internal scripts (particularly as it relates to creating workers in RomPatcher.js for example) rely on this specific structure. It would be nice if imports were a lot less absolute and more relative, so that we might be able to import these in arbitrary folders irrespective of position relative to the root directory (so, for example, static/Rompatcher/js/RomPatcher.js should work rather than just /js/RomPatcher.js).

[marcrobledo]

I'm aware the code structure is a mess haha

But the whole patch creation/application logic is outside RomPatcher.js, inside the js/formats folder there is a single .js for every patch format. MarcFile.js and crc.js would be the only additional files needed to make them work.

Any way, my idea was to create a package that could be just downloaded from here and reuploaded somewhere else, so any translation team could easily offer a simple drag and drop solution in their websites for their own patches, without having to mess with paths nor code. They would only need to specify a PREDEFINED_PATCHES object in index.html and customize the css file.
The only paths that need be changed are the service workers references. I had to use absolute paths in order to make it work correctly in GitHub Pages.

But I'm open to hear any ideas in order to improve it. As I said, I'd like it to become a copy-and-paste solution for everyone, so any suggestions are welcome.

[Mode8fx]

Seconding this request. I'm working on a Python batch patcher (something that takes a folder of patches as input and applies them to the appropriate roms in your rom directory) and it would be great if I could simply call applyPatch() from RomPatcher.js instead of having to hunt down multiple CLI-compatible patchers.

[HeuristicPerson]

@GateGuy, you can easily call Marc's patcher from Python using selenium. I actually created a CLI interface with just 162 lines of code. Please let me know if you're interested and I'll publish it.

PS. Anyway, I completely agree that ideally the patcher should already be divided into front/back ends so you can completely forget the web interface when not manually using the patcher.

[Mode8fx]

@HeuristicPerson If you don't mind, that would be great. I wrote a (messy) downloader about a year ago that uses selenium with the Romhacking.net version of Marc's patcher, but I want to make something that works offline and doesn't rely on a specific browser being installed (mine used a Chrome driver).

[HeuristicPerson]

Published here, @GateGuy: https://github.com/HeuristicPerson/RomPatcherCLI Please note I haven't used it for a long time so I could not work at all. Let me know any problem you may have and I'll take a look.

Regards

[Mode8fx]

@HeuristicPerson Thanks! I was able to combine my old implementation with how you initialized the driver to automate a local copy of Marc's patcher through both Chrome and Firefox. https://github.com/GateGuy/BatchRomPatcher

[eadmaster]

having a node-based CLI interface not requiring a browser engine would be nice...

[theMK2k]

having a node-based CLI interface not requiring a browser engine would be nice...

actually it could be an npm package which is then consumed by CLI, WebApp, Electron App etc.

[unsupo]

#61 should address this as well

[Iranon]

Hi everyone, I have been working on a Tauri app conversion. The service worker logic has been removed in order to make it works locally as an executable. I have developed and tested the patched-ROM generation only in a MacOS environment (ARM Apple Chip) for now.
I should also test the generated ROM in an emulator to check everything is ok.

Despite remaining tests I start sharing the repo here (there is also an Electron-conversion branch).

I would like to open the PR after the ROM working-check.

[Mode8fx]

Hi everyone, I have been working on a Tauri app conversion. The service worker logic has been removed in order to make it works locally as an executable. I have developed and tested the patched-ROM generation only in a MacOS environment (ARM Apple Chip) for now. I should also test the generated ROM in an emulator to check everything is ok.

Despite remaining tests I start sharing the repo here (there is also an Electron-conversion branch).

I would like to open the PR after the ROM working-check.

Instead of testing in an emulator, it may be better to patch a rom manually in the standard web version, patch it with your offline version, and see if the hashes are the same.

[Iranon]

Hi everyone, I have been working on a Tauri app conversion. The service worker logic has been removed in order to make it works locally as an executable. I have developed and tested the patched-ROM generation only in a MacOS environment (ARM Apple Chip) for now. I should also test the generated ROM in an emulator to check everything is ok.
Despite remaining tests I start sharing the repo here (there is also an Electron-conversion branch).
I would like to open the PR after the ROM working-check.

Instead of testing in an emulator, it may be better to patch a rom manually in the standard web version, patch it with your offline version, and see if the hashes are the same.

Nice idea, I'll try in my spare time. I think it will be fine since I barely touched the original code.
Thank you!

[Iranon]

I checked the md5 of the patched ROM generated with the online tool and the local one from my branch: they match.
I think I'll open the PR that might eventually be merged (if useful) to another branch to keep the original codebase separated from the Tauri version.

[Iranon]

I checked the md5 of the patched ROM generated with the online tool and the local one from my branch: they match. I think I'll open the PR that might eventually be merged (if useful) to another branch to keep the original codebase separated from the Tauri version.

PR #70