QuoteBut I can live with another +1.
Yeah, same. It isn't worth breaking all existing patches; or having two versions.
There's still some people that don't trust me over UPS now.
But, you know how I am about perfection. It really gets to me >_<
QuoteYes, of course patch sizes remain identical if you flip that bit.
I meant after compressing it via 7za -9. It was a wash either way.
QuoteWhich is why that one mentions decoder simplicity, not patch size. In particular, these XORs and 1<<7s.
Well I mean it's too late now anyway, but ... if it would've resulted in less code, then that's another unfortunate miss.
QuoteAnd I believe said some are cave dwellers from the era when our feature patches used IPS.
Personally, I don't like multi-patching at all.
UPS had the problem that if two patches changed the same byte, the end result would be invalid no matter what. Both IPS and BPS have the identical problem that the byte will be the result of the second patch.
Both are a big problem. But if I *had* to support it, the ideal way would be, you pick the *original* ROM, then you pick all the patches you want at the same time, which all have the original-file checksum as it should be, and then when the patcher applies them all ... it's an -error- if two files change the same byte of the source file. But that's just me.
You really should be using some other kind of system, like a GUI version that loads assembler patches that can relocate code so all the patches apply safely.
Really ... I think they were trying to justify reasons to stick with IPS instead of using something newer and better. And that's likely why many keep acting like BPS can't multi-patch, even though it can. I don't believe that most of the people even bringing up that point actually care that much about multi-patching -- it's a red herring.
QuoteMost of what would fit in this metadata works at least as well in a readme.
It's kind of a choice thing. The shitty part is how difficult it is to distribute folders on the internet. You have to distribute a ZIP archive or something, and people have to extract it.
Of course, this is undermined by 7za -9 making BPS patches even smaller.
But yeah, people like nitro use it. And it's very simple to ignore the metadata if you don't care about it. It's one offset += readVariableLength();
QuoteInformation directly usable to the patcher, like filenames, could be useful there.
I didn't want to embed filenames into BPS. But if you find that important, BPM embeds filenames. And there's no reason you can't have a single-file BPM patch.
But BPM's main justification is for patching PC-based games that have lots of files. Could also be a smarter way to patch CD-based games than a big BPS patch against an ISO. (of course, the real fun would be applying a BPM patch *against* an ISO ... fun!)
This damn forum software was parsing the HTML variant into a newline, so I had to edit it to that. Technically it should be [br/] but, same problem.
QuoteAnd yes, XML sucks. It's common, but that's its only redeeming quality. Bloated garbage with way too many features, half of which are only useful for XHTML and the other half are security holes. Even without DTDs, why on earth does it have both attributes and inline text, and why do closing tags need to repeat the tag name?
The biggest hell with XML is being able to put elements *inside* of text.
How do you even parse that shit into a node list, I mean seriously?
But yeah, "foo: bar" is so much nicer, both to read and to parse.
QuoteI'm afraid I must veto that one. Either we use full BML, or we use something that doesn't look like BML (INI, for example). If we use almost-but-not-quite BML, someone will miss the memo and use BML's full power, and then all other patchers are sad.
Yeah, but I remember you not liking BML's choices either.
I wasn't crazy about them either. Especially multi-line text. But oh well.
QuoteYou've got dependencies on all kinds of unknown stuff already. You don't understand your kernel's scheduler and file system, libc's condition variables, GTK's styling functions, or whatever OpenGL does, do you? Why would another piece of unknown matter?
So the key goal is to compile out of the box on Windows with a fresh MinGW64 install. Be it TDM, msys2, etc. And ... it does.
Thus, unlike most software projects, you don't have to go fetch zlib, libpng, libcurses, etc.
You're right that on Linux there are more dependencies, like GTK+, because there's just no choice there. I'm not writing my own raw GUI toolkit from scratch (yet...)
I could drop the entire library into beat, but if that library ever gets made into a libsais or something, Linux maintainers will lose their shit over including my own instead of using libsais from the repository.
It's doable, yes. But I'd rather understand SA-IS first.
Quote...wait, you're crazy. Can't really argue with that.
Well, at least I haven't written my own operating system to talk to god (yet...)
QuoteI'll consider it if it becomes more common than IPS/UPS.
Almost nobody fan translates PC games. Those that do just release the whole complete pre-patched game. Most likely because there's not really a good folder patching solution out there.
I still need to finalize the formats, too. I should probably post threads about them. The main discussion is around which metadata to track (file timestamps? Unix permissions? etc.)
Quotestop agreeing when i'm trying to pick a fight
We can always argue about bsnes-mercury instead, if you'd rather
I'm a lot less annoyed now, knowing that the defaults have the hacks disabled, but I'm still really bummed about your unrelenting pragmatism re: DSP firmware. I'm *so* close to getting CV Reynolds to ship the firmware with the individual games ... but I need more impetus.
Maybe I can talk the Snes9X devs into merging a patch from me to replace their HLE with LLE too? Probably not ...
QuoteEasy to veto if you've got the staff team on your side
Specifically, the site admin. But yeah, exactly.