• Our software update is now concluded. You will need to reset your password to log in. In order to do this, you will have to click "Log in" in the top right corner and then "Forgot your password?".
  • Welcome to PokéCommunity! Register now and join one of the best fan communities on the 'net to talk Pokémon and more! We are not affiliated with The Pokémon Company or Nintendo.
    Register

Tool: Patch Checker

LocksmithArmy

LocksmithArmy

Mew!
416
Posts
11
Years
  • Age 35
  • Seen Feb 10, 2024
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.

View attachment 73454

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
 
Last edited:
javcdark

javcdark

no hablo ingles
23
Posts
10
Years
  • Age 36
  • Seen Mar 15, 2020
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

LocksmithArmy

Mew!
416
Posts
11
Years
  • Age 35
  • Seen Feb 10, 2024
javcdark said:
great tool, i'll download it

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

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

Turtl3Skulll

Blue Turtl3
76
Posts
10
Years
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

LocksmithArmy

Mew!
416
Posts
11
Years
  • Age 35
  • Seen Feb 10, 2024
Turtl3Skulll said:
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??
Click to expand...

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

Touched

Resident ASMAGICIAN
625
Posts
9
Years
  • Age 122
  • Seen Feb 1, 2018
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

LocksmithArmy

Mew!
416
Posts
11
Years
  • Age 35
  • Seen Feb 10, 2024
Touched said:
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.
Click to expand...

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

Touched

Resident ASMAGICIAN
625
Posts
9
Years
  • Age 122
  • Seen Feb 1, 2018
LocksmithArmy said:
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.
Click to expand...

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

LocksmithArmy

Mew!
416
Posts
11
Years
  • Age 35
  • Seen Feb 10, 2024
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.

Touched said:
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.
Click to expand...

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

Touched

Resident ASMAGICIAN
625
Posts
9
Years
  • Age 122
  • Seen Feb 1, 2018
LocksmithArmy said:
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
Click to expand...

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

LocksmithArmy

Mew!
416
Posts
11
Years
  • Age 35
  • Seen Feb 10, 2024
Touched said:
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.
Click to expand...

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

Touched

Resident ASMAGICIAN
625
Posts
9
Years
  • Age 122
  • Seen Feb 1, 2018
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

LocksmithArmy

Mew!
416
Posts
11
Years
  • Age 35
  • Seen Feb 10, 2024
Touched said:
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.
Click to expand...

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.
 
You must log in or register to reply here.
Back
Top