Hi there! My name is Brette and I am the Developer of this module and I have a little story to tell if you continue reading about how this project came to be.
I was originally given the task of an auto-patch Discord bot that would process these patches against a comapred ROM, for this I needed a basic understanding of how the ips filetype worked and I spent about a week consitently researching this.
After much time into the projects development I had got in contact witht he owner of the Super Mario Bros 3 Modding Discord and suggested that I make a bot which countered Piracy and if a ROM was present, it would create an ips file for it, while it has the drawbacks of essentially creating other games (assuming they are larger than Super Mario Bros 3) this is to be expected and appreciated as impossible for me to control.
The original ips contrusction code was incredibly crude, producing unoptimized large ips files and did not solve the early EOF issue in which the offset 4542278 was misinterpreted as the footer which serves to terminate patching. It took me about two weeks to create this bot another week spent on the ips construction code and another week spent misunderstanding the discord.py API.
After this I had learned much more Python, as of writing this I am yet to have reached adulthood and am a hobbyist developer who as of writing this can only code in Python and MOS 6502 Assembly. During this time period the AI Assistant ChatGPT was released to the public and I soon found a better teacher than I ever had, while it often suggested minor optimizaitons - the effortless nature in which I recieved answers for any queery I had made learning a fast and fun process which improved my worth ethic, mentality and undoubtly the product quality too.
After reviewing my code on both my Discord bots I had concluded that the code was simply inadequate, I am no perfectionist but if there is an identifiable problem then there is a conjurable solution. After at least a dozen attempts at creating optimized build code, countless tests on instance handling with all of it's unnecessarily helpful and complicated optional kwargs I had created the best ips handler the world has seen.
I have much to be greatful for, if it were not for the incredibly awkardly wrote ips filetype docs that I stumbled on when researching for file structure I would never have gotten to where I am. No one should go through the struggle that I did to get where I am, for this I create the best tool that I can and I offet detailed explanatory documentation on the filetype and the module such that no one should ever be confused about this again.
After effectively completing ips, I decided that the next best move was to begin working on bps. Since then, I have progressed immensly as a developer and can honestly call my past attempts ill-faithed. In tandem with my attempts on bps, I was enlightened by the owner of the Super Mario Bros Discord server (of whom used to have Patchy - as of updating this they have removed it due to the abuse allegations within the server) about a patch file known as nps. From what I here, this was an ips clone that modified per-bank instead of per-rom. It is little wonder that this patch format did not take of, it simply does not solve the issue effectively.
Had you the goal to surpass ips you would not use ips. You would programme an entirely new patching system - what they did here was likely an inexperienced effort to interact with a world unbeknownst to them. Despite my reasonable feelings to lean towards neglecting nps - it honestly costs nothing to integrate. However, I have not found this nps file nor any information on its specification. Should anyone know or find one, I am prepared to programme a handler for it like I did with ips and perhaps even a compiled GUI since it is so niche.
After extensive research into bps, I was able to normalize the file after a long period of time. Now, I could understand the bps file down to its last byte - and here I found some of the constraints of what is considered the best patching filetype to ever exist. Know that, people who use dissasemblies will never encounter this constraint unless they are developing patches.
bps is context-negligent. By that I mean, if there is information that can be copied from source or the current unfinished target then, typically, it will prefer that over storing the patch contents itself - which means that source information must always be a constant. This means, bps is unsuitable for those kinds of patches which exist to enhance the ROMhacking experience.
bps suffices, in fact succeeds, as a production patch format, however it is terribly inadvisable not to be used as a development patch. For it may expect unmodified data in a modified file at an arbitrary offset which, when it was unmodified, had originally stored the contents needed to optimally create the target. After you have wrapped your head around that, you begin to understand why bps is not the be all end all of patches - more still can exist and potentially should!
So I expect you want to know then, if bps file are context-negligent then why do we even have the ability to create and remove the actions within them? That is a good question, I cannot give a good reason as to why someone may feel the need to modify a bps file, however I am merely the tool maker and I have wrote this module in such a way that: if it is possible, then it can be done, if it can be done it will be done.
If that is so then where is patchlib.bps.build? I know, the reason I left that unimplemented was due to the fact it had repulsively long building times even after an incredibly thoughtful amount of thorough refactoring. In consequence of making it faster, we actually made verbose patch files - and the whole point of bps is its context-negligent nature which prioritizes size over speed every time. It appeared that patchlib.bps.build was not able to get the patchlib.ips.build treatment.
Therefore it naturally takes no priority, it is posisble that it may be added at a later date. Yet currently I cannot fathom a user or developer who requires a patch tool that completes at a rate (and this is no joke) ten thousand times slower. Even if the user has an obscure platform, it is still optimal to use ROMPatcherJS at this point. However, should that not be an option then it may be that I programme my own bps build code in patchlib.
But I am more than a mimic, so I began planning my own patch filetype, which is eps or 'Enhanced Patching System'. This will not use the self-referential and fixed-source methodology of bps. Which means that it will produce larger files for production hack ROMs. Therefore, this format should (and likely only would) be used for development patches. Ideally this should replace ips - yet in the world of persistence and legacy it may take time to overcome it. And surprisingly, ips still does the job for some systems.
In it's current state, patchlib only supports ips and bps, however there are immediate plans to approach the different patch types with the same ideology and structure as patchlib.ips. If you have found this tool helpul whatsoever and have read up until this part, please feel free to join the Discord Server where you can see all of my products, including the aforementioned bots that use this module!