Just tossing out thoughts here, so excuse possible repetition of what has already been said by others.
I've read the documentation and the file format. From what I can tell, it's a surprisingly simple yet effective format, not to mention clever. The addition of XML metadata is also neat. It's obvious that this is waaaaay superior to IPS from a technical standpoint. A flag or something to disable checksum checks (from the file itself, not the interface) could be useful for ROM hacking purposes, though. Maybe simply have a "magic checksum" of 0000 0000 for both the target and output files signifying "don't bother"?
The interface could use some slight work, such as a LIPS-like way to choose between creating/applying patches while inside the program. If you want to win against Lunar IPS, you shouldn't overcomplicate things. And, to contradict myself somewhat, I don't agree with your choice to hide the Delta Mode setting from regular users. Having advanced users jumping through hoops just to make regular users stay away from an advanced feature just seems wrong to me. Also, if you're competing against Lunar IPS, you may want it to be backwards compatible with IPS patches to prevent splitting everything into two distinct camps. Having room for a transitional phase seems like a good idea. Also, I don't think it's explicitly stated, so I'll have to ask: Does BPS automatically associate .bps files? If not, adding that is another good idea as LIPS' ability to do that automatically made things even easier.
The point I'm trying to get across is that if you want to compete with LIPS, you shouldn't just compete in terms of the file format (which everyday people don't give a damn about), but also in terms of functionality and ease-of-use.
Originally posted by byuuThe BPS specification is 100% closed. There are no "undefined" cases, or "reserved for future use" values. This helps to ensure that third-parties cannot hijack the specification through viral, non-universal extensions that would dillute the format's universal support.
...except of course for the signature at the start of the file. ;) I'll totally change that to "BPSx" for my own branch that allows you to inline x86 code that's run during the patching process to allow conditional insertion... not to mention malware. Muhahahaetc
...I just realized that the specification actually has a gigantic hole for third party extensions: Tags in the metadata. Nothing prevents third party patchers from reacting to certain tags. <actuallyPatchItProperly/> or <blowUpComputer/> comes to mind.
So. The big question is: Should we use this? It's clearly better, but is it enough to make the switch? Perhaps not, but maybe we should do it anyway? IPS is old as hell and should be retir- wait, no, killed. Wouldn't it be great if we as a community helped give BPS a following, potentially allowing it to spread to other communities and hopefully replacing IPS forever? Creating a new format is a bit of a catch-22. Nobody changes because nobody else changes and it's too much effort to do it anyway. Well, maybe we should actually do it. Sure, we may get tons of whining from ignorant people and some slight whining from smarter people, but in the very long run (and outside the scope of SMWC), I think an adoption of this format would be a good thing. Not to mention that the BPS format is actively developed (right?), unlike IPS which has been standing still for what, 15 years? If we switch to BPS now, it'll then be easy for us to convince people to move to a potential BPS 2.0 down the line which may have more awesome features or stuff like that.
I say yes. Let's deal a blow to the obsolete IPS system once and for all. So what if we have to do some extra work and listen to some whining? Temporary cons for long-term pros.
...the interface could still use some work, though. ;)