We are planning to do a patch remoderation soon (to make the entire section use Asar, and generally clean it up a bit), but first we need to discuss a few things about how patches should be organized in general. Feel free to voice your agreement/disagreement with every one of these points.
First off: With Asar 1.60 it's possible to have a file be automatically included in all patches, making it possible to have a libary of code shared by many patches. There already exists one such library, namely RPG Hacker's shared library, but maybe we should create a new one. Feel free to suggest functions/macros/defines that should be present there.
One idea that is related to a shared library is a set of macros and defines to allow a patch to easily specify tools/patches it is compatible or incompatible with. (See here for an example implementation.)
Next: We have a few patches where things that are intended to be configured by the user are in a separate .cfg file which is included from the main patch (for example the 32x32 player tilemap patch). Should all (configurable) patches be like this? Should we merge the configuration into the ASM file instead?
Should we make all current patches SA-1/SFX compatible? This won't mean that new submissions must be compatible, but it will just be an attempt to make the patches section more SA-1 friendly. It will make the remoderation more time-consuming, however.
Should some simpler patches be converted to UberASM codes instead? UberASM is more versatile, in that you can have it run only in specific levels. However, some users might not like the added complexity of UberASM.
Should there be an "unpatch" included with every patch? My personal opinion is that if the Unpatcher tool can already handle them, then it is unnecessary to include an unpatch too, but if the unpatcher doesn't work on a specific patch then an unpatch should be bundled. I'm against including an unpatch with every patch because it increases the amount of stuff to moderate (including with updates, which might add a hijack but not add it to the unpatch, which could be overlooked), and also that unpatches by themselves have a few quirks that i've seen messed up multiple times.
Should all hijacks used by all patches be logged in the hijack map? That would make it easier to check whether a hijack you are about to use will conflict with another patch.
And lastly: should all patches using free RAM use my new freeRAM tool? More details will be coming shortly (I need to sort out a few things with Asar integration and SA-1), but basically, it keeps track of which empty RAM addresses have been used and which haven't, and automatically picks a block of free RAM with the necessary size. It's also possible to limit the RAM the program will select, for example only choosing from RAM that's cleared at level load or RAM in the $0000-$1FFF range. It would mean that the end user doesn't have to worry about finding free RAM, but in order to be effective, it would have to know about ALL free RAM currently used in the ROM (either by having the user manually input known used freeRAM or having all tools use the freeRAM tool too).
I don't think we'll need helpers this time, but if the remoderation ends up going too slow, it'd be nice to have a list of people we can add as helpers as needed. So, if you potentially would like to help out, please say so.
First off: With Asar 1.60 it's possible to have a file be automatically included in all patches, making it possible to have a libary of code shared by many patches. There already exists one such library, namely RPG Hacker's shared library, but maybe we should create a new one. Feel free to suggest functions/macros/defines that should be present there.
One idea that is related to a shared library is a set of macros and defines to allow a patch to easily specify tools/patches it is compatible or incompatible with. (See here for an example implementation.)
Next: We have a few patches where things that are intended to be configured by the user are in a separate .cfg file which is included from the main patch (for example the 32x32 player tilemap patch). Should all (configurable) patches be like this? Should we merge the configuration into the ASM file instead?
Should we make all current patches SA-1/SFX compatible? This won't mean that new submissions must be compatible, but it will just be an attempt to make the patches section more SA-1 friendly. It will make the remoderation more time-consuming, however.
Should some simpler patches be converted to UberASM codes instead? UberASM is more versatile, in that you can have it run only in specific levels. However, some users might not like the added complexity of UberASM.
Should there be an "unpatch" included with every patch? My personal opinion is that if the Unpatcher tool can already handle them, then it is unnecessary to include an unpatch too, but if the unpatcher doesn't work on a specific patch then an unpatch should be bundled. I'm against including an unpatch with every patch because it increases the amount of stuff to moderate (including with updates, which might add a hijack but not add it to the unpatch, which could be overlooked), and also that unpatches by themselves have a few quirks that i've seen messed up multiple times.
Should all hijacks used by all patches be logged in the hijack map? That would make it easier to check whether a hijack you are about to use will conflict with another patch.
And lastly: should all patches using free RAM use my new freeRAM tool? More details will be coming shortly (I need to sort out a few things with Asar integration and SA-1), but basically, it keeps track of which empty RAM addresses have been used and which haven't, and automatically picks a block of free RAM with the necessary size. It's also possible to limit the RAM the program will select, for example only choosing from RAM that's cleared at level load or RAM in the $0000-$1FFF range. It would mean that the end user doesn't have to worry about finding free RAM, but in order to be effective, it would have to know about ALL free RAM currently used in the ROM (either by having the user manually input known used freeRAM or having all tools use the freeRAM tool too).
I don't think we'll need helpers this time, but if the remoderation ends up going too slow, it'd be nice to have a list of people we can add as helpers as needed. So, if you potentially would like to help out, please say so.