Tool: Patch Checker

[LocksmithArmy]

Have you ever wanted to put more than one patch onto a ROM? maybe you like the moemon patch or another graphic patch ontop of a full hack...

Ever needed to know if the two patches will play nice together...

I have just the tool for you.

"image removed"

The Patch Checker compares all the bytes changed in the 2 .IPS patches and gives you a percentage as to how compatible they are. the higher percentage the less glitches you will have when patching them in the same ROM.

Load 2 separate .IPS files and click "check". its as simple as that.

this tool currently only checks IPS patches, if anyone knows the format (or wants to toss a link at me) for other patching files I will incorporate them...

Version 2.0
View attachment LSA - Patch Checker.zip

UPDATE: Reports are now supported

 

[javcdark]

great tool, i'll download it

you could put the option to create a log to know what are the offsets that are overwritten

 

[LocksmithArmy]

great tool, i'll download it

you could put the option to create a log to know what are the offsets that are overwritten

I tried this... im still working on it but i removed the option cause it took forever, like 30 mins for small patches... hours for big patches... I am working to make the algorith faster, so expect an update eventually

 

[Turtl3Skulll]

Dood, this was so worth the download:) Love the idea:)

One question though I inverted the two patches I used; patch A in slot B(2), and patch B in slot A(1), and I got a different percentage then when patch A was in slot A, and B in B.
Any idea as to why??

 

[LocksmithArmy]

Dood, this was so worth the download:) Love the idea:)

One question though I inverted the two patches I used; patch A in slot B(2), and patch B in slot A(1), and I got a different percentage then when patch A was in slot A, and B in B.
Any idea as to why??

This is because patching order matters. Its really how compatible the second one is to the first one. what percentage of the first patch persists after patching the second one. Order always matters, patch your least important ones first.

For example if your patch makes fakemon and your second patch gives 4th gen sprites, you would put the old poke sprite over the fakemon. So patch the graphics patch first so all the pokes will have 4th gen sprites except the fakemon cause they were changed in the bigger hack.

Its a good idea to patch the important stuff last.

So, again. The percentage is how much of the 1st patch will not be overwrote by the 2nd patch... hope that explains it

 

[Touched]

What language is this written in? It shouldn't be that difficult to log what offsets are used. You should do some profiling to see whether its you actually reading the patch that's causing the slow down, or you writing the results to the log window. I'd guess the latter, unless you're doing something horribly wrong with the reading of the patch. You could trying buffering the entire patch to memory, especially if you're seeking through the file a lot.

Though I been surprised at how some people decide to implement their patching algorithms. The original UPS tool takes ages, not because the format is bad, but because whoever wrote it thought it would be a good idea to read the file one byte at a time using a tiny read buffer and then seek around a lot. If you're using a high-level language, this shouldn't matter too much.

Instead of writing to a log window, try dumping to a text file instead and see how long that takes. If you only use one write operation to do this, it should tell you what the culprit is for your drastic loss in speed.

 

[LocksmithArmy]

What language is this written in? It shouldn't be that difficult to log what offsets are used. You should do some profiling to see whether its you actually reading the patch that's causing the slow down, or you writing the results to the log window. I'd guess the latter, unless you're doing something horribly wrong with the reading of the patch. You could trying buffering the entire patch to memory, especially if you're seeking through the file a lot.

Though I been surprised at how some people decide to implement their patching algorithms. The original UPS tool takes ages, not because the format is bad, but because whoever wrote it thought it would be a good idea to read the file one byte at a time using a tiny read buffer and then seek around a lot. If you're using a high-level language, this shouldn't matter too much.

Instead of writing to a log window, try dumping to a text file instead and see how long that takes. If you only use one write operation to do this, it should tell you what the culprit is for your drastic loss in speed.

I am using C#.
Yes its the writing to the screen that is taking a long time (to publish this, all I did was comment out the 2 writing lines).

My plan (when I get around to implementing it) is to write them to a buffer, and print the buffer at the end, in the hopes that storing a buffer is faster than printing to screen.

I considered making a results.txt but it would just be something to delete (i would delete it). but maybe a "Save" button the would let the user select where to save the results would be helpful for the advanced hackers. I really want users to be able to see the locations that would be overwritten so they can go in and look at what may be glitched... its far better trouble shooting.

 

[Touched]

I am using C#.
Yes its the writing to the screen that is taking a long time (to publish this, all I did was comment out the 2 writing lines).

My plan (when I get around to implementing it) is to write them to a buffer, and print the buffer at the end, in the hopes that storing a buffer is faster than printing to screen.

I considered making a results.txt but it would just be something to delete (i would delete it). but maybe a "Save" button the would let the user select where to save the results would be helpful for the advanced hackers. I really want users to be able to see the locations that would be overwritten so they can go in and look at what may be glitched... its far better trouble shooting.

Buffering sounds like a good solution, especially if you're printing all in one go. I do not know C#, so I can't help you much beyond that.

Also, I know the structure of UPS and some other formats. Let me know if you need them and/or sample code.

 

[LocksmithArmy]

UPDATE:
Reports are now supported :) yay

a report tells you how many records are in each file, how many records are causing errors and each offset that is overwritten in patch one and does the overwriting in patch two... and it also give each byte for each of those offsets.

Buffering sounds like a good solution, especially if you're printing all in one go. I do not know C#, so I can't help you much beyond that.

Also, I know the structure of UPS and some other formats. Let me know if you need them and/or sample code.

I went with a report.txt file... cause it seemed fall out of my fingertips when I was rewriting the code lol.

I have the formats for NINJA(1 and 2) and UPS... I just need to get off my bum and code it in.

if you've got any others, id happily take them

 

[Touched]

UPDATE:
Reports are now supported :) yay

a report tells you how many records are in each file, how many records are causing errors and each offset that is overwritten in patch one and does the overwriting in patch two... and it also give each byte for each of those offsets.



I went with a report.txt file... cause it seemed fall out of my fingertips when I was rewriting the code lol.

I have the formats for NINJA(1 and 2) and UPS... I just need to get off my bum and code it in.

if you've got any others, id happily take them

I know PPF, but I doubt that's of much use. What other formats are there? The only ones used around here are IPS and UPS, it seems.

 

[LocksmithArmy]

I know PPF, but I doubt that's of much use. What other formats are there? The only ones used around here are IPS and UPS, it seems.

Someone on romhackers suggested a bpf... patching files for any system or any style of hacking should be just as easy to sompare. The tool can be universal, not just for pokehacking

 

[Touched]

Since you're doing this in C#, are you inheriting from a generic Patch class? You should probably do that and expose a generic interface for each type of patch, if you aren't already. A suggestion would be to create internal records (each record being a class) using an offset, length, base data, modified data as members. This would make it ridiculously easy to implement other patching formats, as they all use this sort of format. All you'd have to do is XOR or RLE encode the data or whatever, as well as write the appropriate file header.

Have you considered making this tool create and apply patches? You could also try your hand at merging patches into one, automatically relocating records (only ones that are in free space) so that patches are more compatible (with repointing), and even converting patches (though you wouldn't be able to do this for many patch types without the base ROM). I remember doing stuff like this when I first started programming and it was a lot of fun; I learned a lot in the process.

 

[LocksmithArmy]

Since you're doing this in C#, are you inheriting from a generic Patch class? You should probably do that and expose a generic interface for each type of patch, if you aren't already. A suggestion would be to create internal records (each record being a class) using an offset, length, base data, modified data as members. This would make it ridiculously easy to implement other patching formats, as they all use this sort of format. All you'd have to do is XOR or RLE encode the data or whatever, as well as write the appropriate file header.

Have you considered making this tool create and apply patches? You could also try your hand at merging patches into one, automatically relocating records (only ones that are in free space) so that patches are more compatible (with repointing), and even converting patches (though you wouldn't be able to do this for many patch types without the base ROM). I remember doing stuff like this when I first started programming and it was a lot of fun; I learned a lot in the process.

Yeah thats pretty much the jist of it. Every record has an offset, length and data(bytes). A record is universal it should be implemented with any patch type.

I have thought of letting the tool implement/make patches... but thatll be something for the future...

I have also thought of combining patches giving the user the option to pick which patch part gets used if there is a conflict... it would be difficult to move data because i would need to find the pointer to that data which may not be in the patch itself... talk about a dynamic tool.

This tool has the potential to evolve alot i see. Maybe a universal patching suite or something.

 

[LocksmithArmy]

This tool has been reuploaded since the hack.