Language…
13 users online: Batata Douce, CalHal, crocodileman94,  Deeke, dotCoockie, dubiousdinobot, Dzing, Edu X, Hammerer, MegacesarCG,  Saphros,  shovda, StarWolf3000 - Guests: 264 - Bots: 294
Users: 64,795 (2,378 active)
Latest user: mathew

BPS: A new patching system

Info here and here.

BPS is basically a brand-new system for storing data differences between files, similar to IPS and made by byuu. It supports files of any size, tends to make significantly smaller patches than something like IPS, and supports metadata, among other things. And I must say, I see no reason why we can't use this instead of IPS (except for the whole "stick to the status quo" argument, which is never a good excuse for anything). Several other people know about BPS, but apparently nobody else thought to make a discussion thread about it, so...here it is.

----------------

I'm working on a hack! Check it out here. Progress: 64/95 levels.
Bleh. I didn't want to introduce it to the masses here just yet <_<

Problem is, while I full-heartily support The BPS format, as it stands now converting is fairly useless.
As long as Lunar Magic features an IPS patcher, as well as having 600+ ips files on this site, switching over won't be easy =/

We discussed this to great lengths, and the best solution we came up with was a patcher that could apply both bps as well as ips patches, which would make things even more complicated for a newcomer...


Also, for the sake of it, here is some comparison done by byuu:
Originally posted by byuu
Some measurements.

bsnes_v078 -> bsnes_v079
IPS: 1,245,975 (466,666)
UPS: 1,279,504 (1,066,253)
XD0: 357,276 (224,722)
XD9: 195,844 (151,888)
BPS: 234,315 (199,545)

Here, delta patchers far outshine linear patchers. Xdelta3 -9 wins, but not by a massive amount.
UPS is the big loser, being unable to compress itself.

Der Langrisser (J) -> (U)
IPS: 858,833 (831,110)
UPS: 854,756 (831,105)
XD0: 849,758 (821,608)
XD9: 816,436 (811,796)
BPS: 823,917 (822,164)

Here, nothing is a clear winner. The DL data is mostly encrypted, so nothing can make a dent in it. Tie.

Mystic Ark (J) -> (U)
IPS: 364,984 (198,873)
UPS: 368,276 (328,162)
XD0: 342,946 (200,164)
XD9: 219,223 (195,814)
BPS: 252,938 (226,655) [linear=192,807]

Here, delta mode is superior when uncompressed, and linear mode is better when compressed.
BPS again ranks between Xdelta -0 and -9, but can outshine when linear mode is used with compression.
UPS again shows that it cannot be compressed.

Far East of Eden Zero (J) -> 48mbit
IPS: 4,130,818 (3,914,980)
UPS: 5,273,465 (5,113,291)
XD0: 70 (54)
XD9: 70 (54)
BPS: 48 (48)

Here, linear patchers are usless. UPS is out in center-field this time with file sizes.
BPS and Xdelta both handle this just fine. Tie.

Conclusion:

Xdelta compresses better, but is a vastly more complicated spec:
http://tools.ietf.org/html/rfc3284 (29 pages)
BPS can be described on a single page. It straddles in the middle, besting IPS/UPS and supporting delta encoding, while remaining almost equally complex.
I discussed this in #serioushax a few days ago. I can't see why we shouldn't stick to IPS.

Have we ever had any serious, genuine, reoccuring problems with IPS? If not, then I can't see why we should switch over to BPS. Besides, we need a more user-friendly version of BPS. I'm pretty sure noobs have difficulties figuring out how to use command-line tools to begin with.

If we're oh so eager to switch, it would be cool if FuSoYa creates a very user-friendly Lunar BPS or something, and completely removes IPS features from all of his tools. I mean, I could go ahead and remove all IPS-related stuff from the tools section, but LM's IPS patch feature could prove troublesome as many beginners would still use it.

This is my point of view anyway.
My blog. I could post stuff now and then

My Assembly for the SNES tutorial (it's actually finished now!)
Um, yeah... bps does actually have a GUI. You only need the command line to create patches. >_>
Please do some research next time instead of just making assumptions.

Also, the reason for converting to bps is quite easy; it's tons better.
Besides using less space, it also has metadata support, which is the most important feature for me.
Originally posted by Sind
Um, yeah... bps does actually have a GUI >_>
Please do some research next time instead of just making assumptions

I know. What I mean is I open BPS and all I see is apply patch. Pretty sure new people won't be able to figure out how to create a patch. I do know you have to pass a command-line argument to that thing to open it in patch creation mode...

Space is not a problem at SMWC at the moment, and I have no idea what metadata is. I'll look into it later, I suppose.

e: Switching from IPS to BPS shouldn't be a problem I think, I heard there's -something- out there which converts IPS to BPS.
My blog. I could post stuff now and then

My Assembly for the SNES tutorial (it's actually finished now!)
Problem with IPSWhy it's not a problem for us
It's limited to 16 megabytesNobody uses that big ROMs around here
Nothing can start at the offset "EOF" (around 4607814)Nobody uses that big ROMs around here, IPS patchers can solve it by adding another byte (offset EOE is harmless)
No metadata supportI can't think of any reason why this can't be in a readme or something
It's not reversibleBPS isn't either, and there's no need to unapply a ROM hack
It's not a delta patcher, making patches huge if data is inserted at the beginningNobody ever adds data at the beginning of the ROMs around here
We have hundreds of IPS patches around hereWe've got a bunch of skilled programmers here, some of us can easily make scripts to fix up the entire hack section
It's possible to enter the clean and edited ROM in the wrong order, making a patch do nothingBPS doesn't check for that either, unless the hack author tries applying the patch to a clean ROM (not all of them does this)
It doesn't check that it's patched to a valid ROM, meaning a patch made for a headered ROM (or E vs U) can be applied to an unheadered ROM and no problems appears until it's run in an emulator...anyone dumb enough to use wrong ROM doesn't deserve being here?
Edit: Added a new one
<blm> zsnes users are the flatearthers of emulation
> We discussed this to great lengths, and the best solution we came up with was a patcher that could apply both bps as well as ips patches, which would make things even more complicated for a newcomer...

I suppose I can make my tool apply IPS+UPS+BPS; but I don't intend to allow it to create anything but BPS.

> Space is not a problem at SMWC at the moment

So why do I have that huge banner at the top, with all the fancy URL generating tricks? :/
Space=Bandwidth=Money.

> I discussed this in #serioushax a few days ago. I can't see why we shouldn't stick to IPS.

I agree, and I have three more reasons to stick with IPS:

1. patches must be created against headerless ROMs. bsnes and Snes9X will strip headers first, which will allow the BPS patch to work on both headered* and headerless ROMs at the same time (*9x only.) We'd need a separate bps-snes to do this transparently.

2. the default mode validates checksums, which prevents stacking patches. Checksums can be ignored, but that will be a separate option.

3. UPS failed, so how can you trust me now on BPS?

Can I please ask that there not be any discussion about adopting any of my stuff here officially, ever? My stuff always offers tons of new benefits, then we have a feigned discussion about trade-offs, and it always comes down to "change is bad." I'm okay with that!, it's your site, your rules ... I just don't like wasting my time when the outcome is always a foregone conclusion.

That said, I'd love to hear what you guys think about my stuff, including BPS. The more feedback I get, the more I can improve! Let's just not approach it like we have to convert the world, or change any rules here. That's really not necessary.

> Pretty sure new people won't be able to figure out how to create a patch.

What's more likely? A casual gamer not knowing whether to click "apply" or "create" in Lunar IPS; or a ROM hacker not knowing how to specify a program argument or create a text file?

I can post a bps-create.exe that defaults to creation mode when given no arguments. I could also include bps-create.bat with the program. But do you think new people would be able to figure out how to unzip a file?

> Nobody uses that big ROMs around here

Nobody's made use of the ExHiROM/ExLoROM option from Lunar Magic for a 5-6MB ROM? That's a shame.

> ...anyone dumb enough to use wrong ROM doesn't deserve being here?

Interesting. You don't want to cater to casual gamers that can't add or delete binary headers from their ROMs; and Ersanio is worried about hackers who can't use a command-prompt. Quite the difference in perspective between you two.

> Nobody ever adds data at the beginning of the ROMs around here

Delta makes smaller patches, even on linear ROMs. Mystic Ark goes from 365KB to 253KB. Bandwidth bill goes from $365/yr to $253/yr.

> I can't think of any reason why this can't be in a readme or something

It's nice to only have to distribute one file, and not have to compress it first. One less step to play the game. Harder for casual users to remove the readme when redistributing.

Anyway, I planned for BPS to not catch on. SMWC doesn't like change, RHDN doesn't like change and hates my guts, and ZSNES still lacks 2007-era UPS support. Ergo ...

The metadata is going to be accessible from within the emulator (think Help->Patch Instructions.) The metadata is also going to be tied into an online database, similar to my built-in cheat code database.

This database makes cooperation or adoption completely unnecessary. We can convert IPS->BPS for any meaningful patch ourselves. Gamers can load SMW, choose "Find Patches", and get a nice popup list. Select, hit okay, play.

Browsing SMW Central for patches will be as antiquated as browsing adware sites for Game Genie codes when all is ready. And for those that won't use my emu or database, well, their loss I suppose =)
Originally posted by byuu
SMWC doesn't like change


I'd like to state that SMWC has definitely changed its standards ever since the development of BSNES. Saying that we don't actually change isn't speaking the truth - far from it, as we have changed a darn lot regarding accuracy standards. I'd merely have to name the music section as example. But then there's more (for example, read the patch submission guidelines and you'll see).

However, something such as BPS - which in my eyes is not really obsolete, but neither is it necessary for us to implement - should wait a while. There are priorities, and while it may be great and all, we actually need to get more important things rolling (what with the hack and section moderation, implementing accuracy standards there). First things first.
--------> Don't follow "Find Roy's Dignity", my hack. Because it's pretty outdated. <--------
Quote
So why do I have that huge banner at the top, with all the fancy URL generating tricks? :/

I don't really get what you're referring to here, but I don't think I should care. I understand the statement below that one, though.

There are also casual gamers who just started hacking, completely new to the world of ROM hacking. What if these guys wanted to submit a BPS patch of their newly made hack, but didn't know how to use a command-line tool because they're like complete amateurs? Even though this might sound ridiculous, I've met a few completely new ROM hackers like this before. Either way, command-line isn't my main concern right now. I'll worry about that once we decide to switch to BPS for some reason.

In my opinion I just don't see the need to switching our standards to BPS at the moment. IPS works just fine for SMW hacks at the moment. Personally I'd switch once we started to get serious trouble from the IPS format, which isn't anytime soon in the SMW hacking scenes anyway.
My blog. I could post stuff now and then

My Assembly for the SNES tutorial (it's actually finished now!)
I too believe you have misunderstood SMWC a little bit, byuu.
It's not that we don't like change; It's that change isn't that easy =/

One of the problems that I have discovered from seeing you make various tools over the years is that you always go for what you believe is best, and don't care any for backwards compatibility. This is often the best solution, and hell, there's no way I'd want bsnes(or any emulator) to have any of that ZSNES crappyness, but when there's more than ~200 hacks on the site that won't work on a real SNES, it's very hard for us to move away from the zsnes emulator, especially when most of us can't be bothered with downloading more then one emulator(not to mention checking through every rom to see if they are snes-compatible, perhaps only to discover an error far into the game).

And it's that exact same problem that hinders us from using, say, bass. There are ~400 patches, ~400 blocks, and a fair amount of sprites designed for use with xkas on this site, none of which can be assembled with bass. And believe me, there's nobody here who is stupid enough to go through the hell of converting over 1000 patches from one syntax to another(Hell, we're still having trouble porting some TRASM sprites over to xkas XD)

Anyways, back to the matter at hand

>I suppose I can make my tool apply IPS+UPS+BPS; but I don't intend to allow it to create anything but BPS.
This was my original idea as well =P
But I figured it would be fairly pointless since Lunar Magic can create IPS patches itself anyways =s

>Can I please ask that there not be any discussion about adopting any of my stuff here officially, ever? My stuff always offers tons of new benefits, then we have a feigned discussion about trade-offs, and it always comes down to "change is bad." I'm okay with that!, it's your site, your rules ... I just don't like wasting my time when the outcome is always a foregone conclusion.
I am sorry, but you are not in the league to hinder us from talking about your stuff. =/
Now, if you were to disallow us from uploading any of your tools to the central however, we probably wouldn't have any reason to discuss the matter :V
Also, no one is forcing you to waste your time on us. Feel free to leave the discussion at any time if you wish ^-^

>In my opinion I just don't see the need to switching our standards to BPS at the moment. IPS works just fine for SMW hacks at the moment. Personally I'd switch once we started to get serious trouble from the IPS format, which isn't anytime soon in the SMW hacking scenes anyway.

See, let me put it this way:
I want to upload my hack as an bps
Now, given the current circumstances, I would be forced against my own will to patch the rom to an ips instead, a filetype that is worse then the one I originally wanted to submit.

Can you spot the flaw in the current system?
I propose an extremely easy solution:

Just let SMWC accept either IPS or BPS patches for hacks. Let the hack author decide which to use.

I should also note that I don't think it'd be an issue if the hack zips contained a BPS patcher. Some of the hack mods are a little asinine about including potentially worthless stuff with hacks, but I seriously doubt the tiny boost to download size will hurt anyone. It could prove extremely useful to newbies, which are the ONLY ones who can be significantly inconvenienced by this.
One of the main points with bps is to reduce filesize in the first place -_-l|l

As it stands right now, I still believe having an all_patcher tool replacing Lunar ips in the tools section would be the best solution
Originally posted by byuu
1. patches must be created against headerless ROMs. bsnes and Snes9X will strip headers first, which will allow the BPS patch to work on both headered* and headerless ROMs at the same time (*9x only.) We'd need a separate bps-snes to do this transparently.

They do? Why is that? I thought that BPS could be used for any data...or do you mean they do if the emulator itself is creating or applying the patches?

Originally posted by byuu
Can I please ask that there not be any discussion about adopting any of my stuff here officially, ever? My stuff always offers tons of new benefits, then we have a feigned discussion about trade-offs, and it always comes down to "change is bad." I'm okay with that!, it's your site, your rules ... I just don't like wasting my time when the outcome is always a foregone conclusion.

That said, I'd love to hear what you guys think about my stuff, including BPS. The more feedback I get, the more I can improve! Let's just not approach it like we have to convert the world, or change any rules here. That's really not necessary.

All right. Just plain discussion about the stuff itself, then, rather than whether we should or should not use it? I can see why you feel that way, though....

Originally posted by byuu
Nobody's made use of the ExHiROM/ExLoROM option from Lunar Magic for a 5-6MB ROM? That's a shame.

Very few, if any, patches or tools work with ROMs above 4 MB, which I imagine is the biggest reason (and what vanilla hack would need that much space?). Also, >4 MB -> no FastROM.

Originally posted by Ersanio
Personally I'd switch once we started to get serious trouble from the IPS format, which isn't anytime soon in the SMW hacking scenes anyway.

Maybe once hacking GBA games becomes more popular?

...So, I suppose there's nothing inherently wrong with IPS patches, at least for SMW hacks, but what of the users who want to use BPS (and the like)? Maybe it is not and never will be the standard, but I think it should at least be available for those who want to use it. I think forcing everyone to use IPS (or xkas 0.06, headered ROMs, etc.) is as bad as, if not worse than, forcing a switch to newer tools. I mean, my personal plan was to design my hack with an unheadered ROM, have all my patches in bass format (unless p4plus2 finishes chasm in the next week), and make a BPS patch out of the finished product, and if somebody doesn't like it, well, that's just too freakin' bad. Heck, if working around some of the things Lunar Magic does becomes annoying enough, I might forgo the editor entirely and just do like Alcaro and Smallhacker and make hacks in .asm files.

----------------

I'm working on a hack! Check it out here. Progress: 64/95 levels.
Originally posted by byuu
Can I please ask that there not be any discussion about adopting any of my stuff here officially, ever? My stuff always offers tons of new benefits, then we have a feigned discussion about trade-offs, and it always comes down to "change is bad." I'm okay with that!, it's your site, your rules ... I just don't like wasting my time when the outcome is always a foregone conclusion.


It just slightly annoys me that you seem completely unable to see any other reason besides "change is bad" that any one wouldn't use your software. I think the real reason mostly is that you refuse to make concessions for anybody. And you know that is a good thing in the long run, but the idea that everyone who doesn't immediately embrace your way of doing things as "superior" is "stuck in the past" is a absurd and insulting one.

Look at the whole addmusic fiasco for example, were as soon as something better came along there was a massive push to adopting it, all the music got updated, and using the old one was now no longer acceptable. I thought we should have waited for a while, but overnight everything changed. It's not impossible.

I don't like IPS that much more then you do. It's a clunky limited patching format that should have been retired long ago. Honestly the only reason it hasn't is there are tons of patchers and creators for it laying around. A IPS function is even built into zsnes. There is simply no other patch format for roms as widely supported.

But IPS is inappropriate for anything bigger then 16MB, and as far as I know, no patching standard has yet emerged for, say, DS roms, though I have seen xdelta used a fair bit. BPS needs to find it's place to grow, and when people support it, of course we will to. I would like IPS to be replaced, but we don't use IPS patches because they are better, we use them because they are widely supported.

On the other hand, if we support BSP, maybe other people will too.
Your layout has been removed.
Originally posted by Sind
One of the main points with bps is to reduce filesize in the first place -_-l|l

Filesize is an extremely trivial concern for what we do here.

Quote
As it stands right now, I still believe having an all_patcher tool replacing Lunar ips in the tools section would be the best solution

This would work fine, I think.
Originally posted by byuu
1. patches must be created against headerless ROMs. bsnes and Snes9X will strip headers first, which will allow the BPS patch to work on both headered* and headerless ROMs at the same time (*9x only.) We'd need a separate bps-snes to do this transparently.

Yes, that's another advantage: We won't need to care about whether our ROMs are headered or not, the patches will still work.
While having to make another tool could make stuff trickier, it could also make other stuff easier (not having to care about headers could be very useful for some of us).

Quote
2. the default mode validates checksums, which prevents stacking patches. Checksums can be ignored, but that will be a separate option.

While that argument would make sense for these (which aren't IPS), we're not talking about that. We're talking about this, and applying two of those on the same ROM is about as intelligent as applying two translation patches on the same ROM, or a bsnes079->080 patch on 078.

Quote
3. UPS failed, so how can you trust me now on BPS?

You may have a point there.
It's not really a good argument, but it's not void either.

Quote
I can post a bps-create.exe that defaults to creation mode when given no arguments. I could also include bps-create.bat with the program.

Do like this tool and allow both.

phoenix and nall should make it a ten minute job.

Actually, I might as well do it myself.

Quote
> Nobody uses that big ROMs around here

Nobody's made use of the ExHiROM/ExLoROM option from Lunar Magic for a 5-6MB ROM? That's a shame.

Lunar Magic and snes9x are the only tools that support ExLoROM, so we just tell people to avoid it entirely. It's easier that way.
It's like unheadered ROMs: Half of our tools are incompatible with that too.

Quote
> ...anyone dumb enough to use wrong ROM doesn't deserve being here?

Interesting. You don't want to cater to casual gamers that can't add or delete binary headers from their ROMs; and Ersanio is worried about hackers who can't use a command-prompt. Quite the difference in perspective between you two.

That argument was more "I don't have any real arguments, so let's just pull out something half serious" than anything else. It means "checksums are useful and I can't think of any argument against them".

Quote
> Nobody ever adds data at the beginning of the ROMs around here

Delta makes smaller patches, even on linear ROMs. Mystic Ark goes from 365KB to 253KB. Bandwidth bill goes from $365/yr to $253/yr.

You have a point there. Two-byte RLE could be useful for some of our data.

Quote
(stuff about metadata, too long to quote)

"I can't find a reason for that" doesn't mean "there is no reason for that". You have a point there.
Some of us, for example me, prefer hard-patching our ROMs, but that's why hack descriptions exist.

Originally posted by Ersanio
Quote
So why do I have that huge banner at the top, with all the fancy URL generating tricks? :/

I don't really get what you're referring to here, but I don't think I should care.

He means the ads.

Originally posted by Sind
I am sorry, but you are not in the league to hinder us from talking about your stuff. =/

He can't forbid us from it, but he can ask us to do it. We don't want to annoy him, he is fully capable of doing a lot of stuff we don't want.

(I know that parts of this post is duplicates of earlier posts, but this thread moves ridiculously quickly. There's ninjas everywhere.)
<blm> zsnes users are the flatearthers of emulation
Aren't we really just quibbling over the difference of (over the course of the entire site's IPS-related contents) maybe ~20-40 MB in saved/compressed space all told? To me, that's really not anywhere near enough to make adopting a different tool worthwhile. (Note: I acknowledge that Byuu is not endorsing that idea.)

If both patchers get the job done, does it really matter which one anyone uses? I mean, this isn't even an instance of "use this patcher or your ROM won't work on a SNES" -- it's two tools that do the same thing in different ways. (That's highly simplifying the situation and ignoring the differences and their merits, but hey, I can do that).

It's wonderful that there are people out there making all of these tools for the casual "hacker" to be able to do fun things with 20-year-old technology. I don't want to dog anyone's work. But, at the moment, some of the dialogue really just seems to be dissolving into whose cult of personality is the biggest.

As far as headered vs. unheadered compatibility goes, sure, that's a clear difference between the tools. It's going to be something that appeals to the purists. That's great. But, are we really at the point where removing a 512-byte header is going to prevent us from playing a hack we really want to play? I get that it's just one extra niggling step that will be obnoxious for anyone who needs headerless ROMs, but honestly, are we adopting these standards because of all the people who actually own a SNES and a flash cart for playing ROMs, or are we catering to an emulator that slavishly strives for accuracy even though you can't stick an unheadered SNES cartridge into your PC?

I'm a layperson when it comes to the technical aspects of many of these things, and I'm being somewhat facetious. In reality, I really do believe accuracy is the best policy. However, I'd also like to just make sure our heads don't all simultaneously get sucked into our own assholes in the meantime.

[?] Miscellaneous Helpful Hints
If I moderated your hack, there was apparently a 90 percent chance it was rejected.
Double-posting for cool points.

I entirely forgot to make the overall point I wanted to make.

Since this is a tool with comparable counterparts, comparisons between them are going to naturally arise in the course of discussion. That's fine.

I guess what rankles me is that this is discussion of a brand new tool. It has several merits that make it better than some of the other tools. Is that a good reason to adopt it as the site's go-to patching tool? No.

We use IPS patches here mainly (I'm guessing) solely because Lunar IPS was developed by FuSoYa, and most of us happen to use another tool made by FuSoYa. So, they sort of go hand-in-hand. We don't use UPS patches or [insert patch format here] because that's just not the way it happened.

Will we ever change? Possibly. But one new tool being announced is no reason to change everything. What if the next one that comes out is light years better for some other reason? Evolution in favor of long-term improvements is great, but there is something to be said about stability, too -- there's no reason to change everything on the site each time something new comes out, unless there is some sort of reason to do so (e.g. blatant incompatibility with a SNES).

[?] Miscellaneous Helpful Hints
If I moderated your hack, there was apparently a 90 percent chance it was rejected.
Allow me to be elitist for one moment.

This community has a serious issue with change. It can't seem to handle it. No, there really isn't anything to be said about stability other than "change might confuse people!" That's not something I'm very sympathetic to. Yes, we should switch to new tools once something better comes out, every time.

End elitism.


User friendliness can be important to drawing in new hackers and letting those who just want to play hacks be able to do so without headache. Patching falls under the latter.

That said, I think it's very possible to preserve user friendliness while still adopting a new patching format. I suggested handing out the new patcher like candy, another suggested replacing LIPS. There are probably more options too. Point is, there are plenty of painless options to completely avoid confusion, so I can't really see opposition to the idea as much more than fear of change. If there were actual hurdles to overcome, then maybe there'd be reason to not adopt it.
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 byuu
The 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. ;)