Language…
6 users online: anoMaly666,  Atari2.0, BabaYegha, Nitrogen, sinseiga, Tsquare07 - Guests: 235 - Bots: 313
Users: 64,795 (2,375 active)
Latest user: mathew

Patch remoderation thread

  • Pages:
  • 1
  • 2
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.
Not having an opinion with every point.

Originally posted by randomdude999
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?

An advantage is that an extenal file can be used by other resources and it's pretty clear which file you have to open. I still feel like it should be up to the patches' creator and doesn't need to be done (although if there are many defines, we certainly should split the file).

Originally posted by randomdude999
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.

It's more work, yes, but it also makes SA-1 (and GSU) more accessable to the public.
Furthermore, there are patches which takes much processing power and therefore can benefit of a boost from the enhancement chips.

That's especially important for GSU (Super FX) because its programming language is different from 65c816 (SNES and SA-1). An example I can think of is NMSTL with its big OAM slot checker. It's one of the things where Super FX can really boost the process (in fact, I already have a GSU NMSTL).
That being said, we need to set some standards with the GSU kit. Like, I use a Super FX define containing Super FX's registers (most importantly, the R registers). It also lacks a way to divide on its own which is another problem we need to solve.
Then again, we need to discuss about Super FX altogether.

Originally posted by randomdude999
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.

A lot of these patches were made before GamemodeASM was a thing (how many patches were submitted which does this thing lately?). Nowdays, we create patches like these for UberASM as the hijack itself doesn't do anything but simply giving the custom code a way to run every frame.
Problems of hijack conflicts may also arise (the $008DC4 case is pretty infamous, esp. since it's located in NMI). Hijack conflicts are also hard to solve if you don't know how to create patches as you'd need to look into the disassembly for a new code and find a good hijack. (The fact that it's unnecessarily clutter up the Hijack page doesn't help.)
I therefore vote for "convert to UberASM".

Originally posted by randomdude999
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.

Going with the case "no unpatcher unless impossible to unpatch".
I do not feel that an unpatch should be a required inclusion. It should be encouraged but not required, given the tools that exist. I do think that we should have a specialized tag for patches that include one though.

Also, as a general suggestion: can we have all "bugfix"-related patches combined into one? Ideally we'd have defines created with essentially ones marked as on by default and others off. However doing this would probably require an unpatch, so that people can disable fixes if it causes issues or conflicts with other patches down the line.



I'll give some quick thoughts on what I care about most.

•SA-1 and SFX compatible: Yes, please and thank you. SA-1 at least should be mandatory if you ask me. Anyone who answers otherwise I see honestly as being lazy and not wanting to put in the additional effort towards a good thing (if they're a ASM mod or patch maker.)
•Simpler patches converted to UberASM: Yes
•Unpatch included with every patch: I agree with Sonikku, encouraged but no required.
•Hijacks logged in Hijack map: Yes
Layout by RanAS, modified by yours truly.

The whole project was discussed separately between me and randomdude999, so our final opinions don't really differ. However, I will give some more details on the project, mostly personal opinions.

No offense to RPG Hacker but I'm not too sure if want to use his library directly. Granted, he's an Asar developer and his library has been proved to work for multiple big patches, but my paranoia can't get over its internal code and external interface. For some reason, I think that adding a define to the end of an address is more predictable (so less error-prone) and nicer-looking than wrapping all addresses in a function call. I feel like this is a rather subjective opinion that will take some discussion before we can actually move on with the remoderation.

I'm also not a big fan of configuration files. The average hacker associates a CFG file with a sprite, which might get really confusing - it's better to keep configuration in an ASM file. No matter which file format you use, however, you could still easily end up with a file which only holds a single define for a 20-line patch, which is honestly a waste. I'd rather just place the configuration at the top and clearly mark where the patch code begins.

Conversion to SA-1 and SuperFX is pretty much required for this day and age, especially with the SA-1 becoming usable on the sd2snes. Documenting things in the hijack map just feels natural and would make conflicts a lesser hassle. I'm indifferent about unpatching mechanisms.

Converting simpler patches to UberASM is definitely a pretty good idea, as long as it doesn't repeat the sprite remoderation - how many generators were removed and never submitted as UberASM in spite of their remoderator's promise? Admittedly, I'm guilty of that, too, and I'd rather not repeat past mistakes. I'm also wondering if we should keep both a patch and an UberASM version, just in case someone doesn't want to use UberASM for some reason.
@Library:
How would the library, and especially updates to the library be handled? With the asar download? It's setup should more or less be a given since people and especially beginners won't want to set up some shared file that doesn't even come with the patch itself.

I do think a shared patch with some functions would be useful but mostly to check for what is applied (Tools (especially spritetools), LM hijacks, etc). I feel like it shouldn't handle conversions like RPG hacker's library seems to do right now.


@Config files
I believe a configuration file can help a patch organization, but could also very well make it a lot more confusing especially, like telinc said, for smaller patches.

I also don't like changing the extension to cfg. When it comes to the extension, I would recommend leaving config files with .asm and make it obvious which is which (e.g. <patch_name>-config.asm). While most of the time the contents of the config file wouldn't actually be asm but only defines it would make sure people don't confuse it with a sprite's cfg file. Most people, even when beginning, also have .asm files automatically open in a text editor, but cfg files possibly automatically open in the cfg editor.

If the patch is big enough for a config file to make sense, then I'd say yes, do move them to an external file. If the patch is only small then the config should be in the patch with a clear separation


@SA-1
My personal opinion on this is that it should be up to the (re)moderator like it was with the sprite remoderation, which makes sense considering that future patches still don't require sa-1 compatibility. However, since this is a mostly "I don't care" driven and not "This could benefit the community" driven opinion I'll just leave this point at that.


@UberASM
If a patch can be made to work with uberasm, I think it can only benefit from being for uberasm, since you will have the option to only have it for a couple levels, or have it still globally apply using gamemode asm.

I do however think that when this is the approach taken, it should be made easier to have multiple files run on the same gamemode.

One idea for that I had is using the library method, however having an tool in-built option to generate the "main: JSL <file_a>_main : JML <file_b>_main" files internally.


@Unpatch
I agree with Sonikku here, the unpatch should be an appreciated but optional extra, most patches can be removed by tools nowadays so having an extra unpatch.asm included with every patch is for most patches unnecessary (also, sa-1-unpatch.asm lol)


@Hijack list
I think this is only useful if it's done consequently and for everything, including tools, lunar magic, uberasm etc
One problem will be optional hijacks, which could (or would have to) be marked with optional in the list but also be described on when they are used.


@"freeRAM"
Well, considering the information on how it actually works is pretty much nothing I'll just add some things you might have to consider or maybe have already considered:

Firstly, compatibility with already existing methods to keep track of freeram:
Whatever your method might be would have to be backwards compatible with existing methods or else it will end up in a situation where people feel forced to change methods but don't want to for their already running projects, which might end up in a similar situation as spritetool (trasm)/pixi (asar)

And secondly, freeram used by other resources.
It would have to be implemented in pretty much all tools that use custom resources (uberasm/blocks/sprites etc) and would have to easily communicate between resources (e.g. a sprite having the same freeram as a block)





Alrighty, I think that should be about it, if you guys do need more people and sa-1 isn't a requirement I'd love to help again, last remoderation was a lot of fun minus the pixi mess it ended up being
Originally posted by TheBiob
If a patch can be made to work with uberasm, I think it can only benefit from being for uberasm, since you will have the option to only have it for a couple levels, or have it still globally apply using gamemode asm.

I do however think that when this is the approach taken, it should be made easier to have multiple files run on the same gamemode.

One idea for that I had is using the library method, however having an tool in-built option to generate the "main: JSL <file_a>_main : JML <file_b>_main" files internally.

This is pretty much the point I tried and failed to make in my last post. The major downside of UberASM in its current state is its inability to use multiple files in one level or gamemode, which is a huge inconvenience if you don't know how to use libraries. This is why I support having both a patch version and an UberASM version - generation tool or not, the only non-confusing way to have multiple files in a level would be to support that from UberASMTool itself.
Quote
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.)


theres so much that could be included in an all-purpose shared library that i dont think its worth doing. maaaaybe just basic stuff (sa1/sfx remaps, fastrom?, etc)

Quote
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 be the patch author's choice. like someone said, if its a 20 line patch with 1 define, then f the config file. only super big stuff should need it (but again, up to author)

Quote
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.


yes do it. shouldve been done ages ago actually

Quote
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.


not everything can be thrown into uberasm. i say no

Quote
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.


biiiiiiiiig no

Quote
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.


no. only major patches. y'all can define "major" at some point

Quote
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).


hmm

this is a good idea in theory. but idk if itd work that well in practice (aka on a wide scale). i say #tb{:?}



good luck LOL
Here's my thoughts on some points.

Quote
Config Files


I think those better to be used for bigger patches and in .ASM format, as telinc mentioned they associate with sprites and can cause confusion.

Quote
SA-1/Super FX support

I'd say leave it up for (re)moderators. If they can and want to convert them, they can do that. They're not obligated to convert everything, even though that would be nice.

Quote
Simple patches -> UberASM


Yes, that would save people from accendially breaking rom because of hijacks, if patch is simple enough to not replace anything in original code, and it's simpler to work with uberASM, especially if you want to remove it if you don't like it.

Quote
Unpatcher


I think it should be totally optional, and better to be included with bigger patches.

Quote
freeRAM tool


Yes, that'd make things better organized in case you forgot which of resources use one or another freeRAM.

Also

Originally posted by Sonikku
Big huge bug-fix patch


I'd say no, it would take some time to ensure every fix in one patch works propertly, nothing conflicts, include necessary additional files that come with one bug-fix patch or another, and it'd be too much space if you want to install just one small bug-fix + what's about bug-fixes in the future? That seems to be time consuming and overall not worth it.
Originally posted by Telinc1
Originally posted by TheBiob

This is pretty much the point I tried and failed to make in my last post. The major downside of UberASM in its current state is its inability to use multiple files in one level or gamemode, which is a huge inconvenience if you don't know how to use libraries. This is why I support having both a patch version and an UberASM version - generation tool or not, the only non-confusing way to have multiple files in a level would be to support that from UberASMTool itself.


I mean, having UberASMTool support that natively was pretty much what I meant. The reason I suggested the library method is that you could have library files in both normal levels, overworld as well as gamemode if you want to since you can't use overworld files as level which is mostly something personal I want and maybe something useful for other people.

Though I guess leaving them in their corresponding folders then generating the files for that makes more sense
Want to give my input on this as well before I forget about it.

Originally posted by randomdude999
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.


Yeah, I definitely support the idea of having a shared library of sorts. Like others I don't think it should necessarily be based of my own lib (I think my lib contains some stuff that is pretty specific to what I needed in my patches), although there definitely is stuff in my lib that could be taken over since it can be generally useful. For example: it has nice little conversion functions for working with 13-bit fixed numbers, which are needed for doing Mode 7. Potentially also a few other things. If we do a shared lib, I suggest calling it "libsmw", putting some useful, SMW-specific stuff into it, and going with a directory structure like this:

Code
-stdincludes.txt
-stddefines.txt
-libsmw/
--smw/
---smw.asm
---[...]


Where stdincludes.txt contained

Code
./libswm


So that way patches using the lib could just do

Code
incsrc smw/smw.asm


I also suggest adding a macro to the lib for version verification. For example, something like this:

Code
@asar 1.60

incsrc smw/smw.asm

%libswm_check_ver(1.50)


This macro would throw error an error if the end user did not have at least libswm version 1.50 in their Asar directory. Something like this would make it easier to distribute libsmw separately from Asar.

Basically the idea is that people just have to unzip libsmw into the Asar directory and only ever update it if a patch specifically requires a new version. I think that would make it simple enough to not be alienating towards less experienced hackers. Anything more complex than this could be problematic to them. We could also distribute future versions of Asar with the most-recent version of libswm at the time pre-included to make things even simpler.

As for content of this lib, there's a few ideas I have already. For example, so far all of the tools we're hosting use different defines to reference certain addresses. We could unify this with an SMW lib by providing standard names like "!smw_PowerUp" (or smw_PowerUp if we wanted to go with labels for RAM addresses, which could be a good idea since Asar can export labels for debuggers to read them). That way tools like GPS, GIEPY etc. could all use the same names instead of each doing their own thing. We could also give names to commonly used routines in SMW. For example, instead of

Code
; Jump to some random-ass address that you will only understand by reading the ROM Map or all.log
jsl $00F606


we could have something like

Code
jsl KillMario


The possibilities here are endless and a lot of benefits could be gained from such a shared lib.

Originally posted by randomdude999
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?


Personally, yes, I think all patches should be like this. I don't think end users should ever have to touch an ASM file unless they're coders themselves and want to actually rewrite code or drastically change its behavior. Even for simple patches with literally only one setting I would still include a separate configuration file. I don't really care what extension that file uses. I used .cfg on my own files because that's a common extension for config files and it also sounds intuitive, but really anything goes. It doesn't have to be .cfg, since people have made a good point against .cfg (it being associate with sprites). The most basic thing would be to just use .txt, which is already associated with a text editor for everyone and doesn't cause confusion with sprites. I would not go with .asm, though, to clearly distinct the config files from the actual code files. We could also standardize, for example, a certain file name and say that all future patches should use a configuration file of that name. For example, "config.txt". This would make it impossible to extract multiple patches into a single directory without using sub-directories, but putting everything into a single directory is bad practice to begin with.

Originally posted by randomdude999
Should we make all current patches SA-1/SFX compatible?


I vote "yes" for SA-1, but as for SuperFX, is that even a thing for SMW right now? I'm not sure, but I'm leaning towards "no" here, because it seems more complex and more time-consuming than it's really worth it right now, plus it could mean less potential helpers, because who here is really familiar with SuperFX?

Originally posted by randomdude999
Should some simpler patches be converted to UberASM codes instead?


UberASM might be slightly more complex (when using multiple hijacks in a single game mode, for example), but it also definitely has the advantage of preventing hijack conflicts when used correctly. I'd vote "yes" here, but only for patches that easily work with UberASM and don't require nasty hacks or anything like that. Basically, only convert stuff to UberASM that nowadays would probably be written for UberASM to begin with.

Originally posted by randomdude999
Should there be an "unpatch" included with every patch?


I vote for "no" here, because it increases the complexity of writing patches, even if only slightly, and I doubt the reliablity of those patches in the first place. Plus, "unpacthing" is a solution to an entirely man-made problem. If the entire SMW hacking infrastructure wasn't as messy as it currently is, unpatching wouldn't be needed in the first place. Even WITH the current infrastructure, it's easy to avoid the problem by always making backups of ROMs and always applying patches last and to a copy of the ROM. This is what I do, and it can be achieved with a simple .BAT script.

Originally posted by randomdude999
Should all hijacks used by all patches be logged in the hijack map?


I vote for "yes", but the Hijack map should be updated in some way to make it easy to differentiate patch hijacks from Lunar Magic hijacks.

Originally posted by randomdude999
And lastly: should all patches using free RAM use my new freeRAM tool?


Tricky to answer because I'm not familiar with that tool. I'd probably say something like "yes if it makes little to no difference to the end user and only a small difference to the patch writer, otherwise no". Like, the end user shouldn't have to do anything more than to download the tool once, everything besides that should work as it used to (aka just run the patch through Asar). If requiring any more effort than that, I vote "no" because I don't think average users would want to deal with that. Similarly, for patch writers, the most amount of effort that should ever be required should be to edit a few defines and maybe add an incsrc or something like that. If using the tool is any more complex than that, I'd vote "no" here.

Originally posted by Sonikku
Also, as a general suggestion: can we have all "bugfix"-related patches combined into one?


+1 for bugfix patch.

Originally posted by Telinc1
however, you could still easily end up with a file which only holds a single define for a 20-line patch, which is honestly a waste.


I disagree on this. User-friendliness is never a waste, and having configuration in a clear and easy-to-find place is definitely always more user-friendly than having users open your code file and look for stuff they can configure or than having to read a Readme to know what lines they can change.

Or if by "a waste" you mean "a waste of space", I agree even less, because noone nowadays will care about the (at most) few kilobytes of extra disk space taken up by moving stuff into a separate file.

Originally posted by TheBiob
How would the library, and especially updates to the library be handled? With the asar download? It's setup should more or less be a given since people and especially beginners won't want to set up some shared file that doesn't even come with the patch itself.


I already covered this further up in my post, but can't hurt to have a short summary here: we could always distribute the most recent version of the lib (at the time of release) with each new Asar version, but also add a separate version of it for download so that we could update it without being force to remoderate Asar all the time. This separtely hosted version would host as a drop-in replacement which people would just have to extract into the Asar directory.

Originally posted by RussianMan
and it'd be too much space if you want to install just one small bug-fix


As already mentioned further above, I don't think "too much space" is really an argument with SMW nowadays. I would be surprised if such a bug-fix patch made it to even 1 MB in size, which isn't really anything nowadays.

Originally posted by RussianMan
what's about bug-fixes in the future?


The popular thing here would be to host the patch on GitHub and let people contribute to it. Though I admit, that is a pretty good argument against it, since it would indeed make it a bit bothersome to submit new bug-fixes.
Feel free to visit my website/blog - it's updated rarely, but it looks pretty cool!
The only opinion I have is on config files: they don't need to always be separate, but if they are, please don't call them .cfg.


 
Misc replies:
Originally posted by RPGHacker
As already mentioned further above, I don't think "too much space" is really an argument with SMW nowadays. I would be surprised if such a bug-fix patch made it to even 1 MB in size, which isn't really anything nowadays.

ROM space is an argument though - there are multiple big hacks that have serious issues with running out of freespace. However, that would be easy to get around by just making defines to control which bugfixes are applied and which aren't.

Originally posted by TheBiob
Firstly, compatibility with already existing methods to keep track of freeram:

Could you name some of those methods? I'm actually a bit curious myself. I've heard "the best way is to just keep track of all freeram in a text file" a few times.

Originally posted by TheBiob
would have to easily communicate between resources (e.g. a sprite having the same freeram as a block)

That's implemented.

Originally posted by Ladida
not everything can be thrown into uberasm. i say no

i didn't say everything. i only meant the patches that are trivial to convert to uberasm

Originally posted by RPG Hacker
the Hijack map should be updated in some way to make it easy to differentiate patch hijacks from Lunar Magic hijacks

i'm sure our coders can figure that one out (by adding a field that says "source" or something to the map)

And I guess I should write more about my freeram tool (it's still not quite done, but coming soon I promise. if you really want to look around then it's on my github). It makes things simpler for the end user because after they set up the tool (which involves replacing the asar exe, adding a dll next to asar and adding a "ram description" file next to the ROM), freeram management will be completely automatic - the user doesn't have to edit patches at all to configure the used freeram.
May I add something to a shared bugfix: The biggest advantage of a shared bugfix is that all of them use a single freespace block (maybe two if freedata and freecode codes are strictly seperated and there might be workarounds for that too) where as with standalone patches you always "waste" eight bytes of freespace with each new bugfix applied into your ROM (save for these whose code is put into the first 512KiB). It's the same reason why yoshifanatic has created a script to remove almost all RATS tags for the levels or why JUMP uses a single ASM file containing multiple patches instead of seperate files. And freespace still can be an issue, at least for large hacks (most famously, Super Wakana Land).

I believe, yes, a single bug fix patch makes therefore the most sense.
I'd love to help with a remoderation again, despite being really low on time and even lower on Internet access. Good news, though - my college listened to my complaint regarding SMWC being blocked, in which I also said I ended up resigning from staff because of that. Only issue so far is with file downloading - some of them will simply not work. Anyway, if nothing else goes wrong, count me in.
MK2TDS
Originally posted by randomdude999
ROM space is an argument though


True, I was referring mostly to disk space in that argument. I took the "only use space on stuff that the user enables" approach for granted.

That being said, are there even many bug fix patches that use freespace? I'm thinking that a lot of bug fixes probably don't even need any freespace to begin with?
Feel free to visit my website/blog - it's updated rarely, but it looks pretty cool!
Originally posted by RPG Hacker
That being said, are there even many bug fix patches that use freespace? I'm thinking that a lot of bug fixes probably don't even need any freespace to begin with?

There are quite a few bug fixes requiring no freespace, though these which do require freespace are in the majority.

mod edit: fixed html
Originally posted by randomdude999
shared library

This would be nice, though I have no idea what it can contain other than defines for FastROM/SA-1/SFX.

Originally posted by randomdude999
configuration

Look, I'm all in for cleanliness in ASM files, but I also wish we could forbid shit like one separate cfg file for only one define, or like 90 configuration files in different directories with a few defines each. I say one cfg/asm/whatever file with defines only when it's needed, and in the same directory as the patch.

Originally posted by randomdude999
SA-1/SFX compatible

Yes.

Originally posted by randomdude999
simpler patches converted to UberASM codes

Yes, but leave a patch version as an option. (and unlike the generators situation let's actually do them instead of rejecting them and never converting)

Originally posted by randomdude999
unpatch

Only if the tool can't with a patch.

Originally posted by randomdude999
log in the hijack map

Yes, the map needs some love. (by the way that section needs its own forum to log rejection reasons of addresses)

Originally posted by randomdude999
all patches using free RAM use my new freeRAM tool

:shrugio:

Originally posted by randomdude999
don't think we'll need helpers

I wouldn't mind getting a bit of help imo, in case other sections get loads of submissions or if a moderator gets busy.
I've been working on making some patches into UberASM code. I've been away but helping remoderate this stuff seems like it'd be fun, and I was wondering why a lot of those patches hadn't been turned into UberASM already :P

Time to become a Productive Member!

(I also am doing the same thing with generators)
There haven't been any more replies for a while so I'm doing a small counting of the responses so far. The bold option is what we'll go with unless more people state their opinion
(in case of ties, my own opinion is what is used)

LIBRARY:
only basic defines/requirement checks - 3
not rpg hacker's one - 2

CONFIG FILES:
yes, but with .asm extension (no for smaller patches) - 4
up to the patch author - 2
no (config at start of ASM) - 1
yes with cfg extension - 1

SA1/SFX:
Yes - 4
up to moderator - 2
If it's not much work - 1
yes but not sfx - 1

UBERASM:
convert - 5
convert but leave the patch - 2
don't - 1

UNPATCHER:
no, unless tool doesnt work - 2
no - 2
encouraged but not required - 3

BUGFIX PATCH:
all-in-one - 3
separate - 1

LOG HIJACKS:
yes - 4
yes, but everything else (uberasm, tools) will have to be logged too - 1
only major patches - 1

VOLUNTEERS:
Darkbloom, Blind Devil, TheBiob (but only if sa-1 isn't required)
  • Pages:
  • 1
  • 2