ROM Hack Patching a patched game?

[Lockon Stratos]

I'm sure it's possible?

 

[ComplicatioN]

should be possible but if u have a patched game wouldn't u have the clean one
-or u got it pre-patched

 

[psycoblaster]

no, if the patch was meant for clean roms (99% of all the patches out there)

 

[Lockon Stratos]

It was just a thought in my head that I wanted to get clear, so now it is so you can just lock it...

 

[FAST6191]

To expand on what psycoblaster said.
You will have to understand how things work with the DS and how patching mechanisms work.
All known commercial DS roms use the nitrorom file system and all I have ever seen use their own file types underneath that. These file types are what makes DS rom hacking easier and harder at the same time (easier as you do not have to worry about space and harder as tracing (a method by which you can determine what does what with extreme accuracy) is nearly impossible.

Patching mechanisms also vary, some of the more modern ones like deufeufeu's patching system and my earlier work with batch files and rom ripping rely on the fact the DS file system exists.

Others like IPS, bsdiff and xdelta work simply by having an address (or three) and replacing the information at the address with the data they hold. It gets far more complex in that IPS has a limit of 16 megs unless you use the hack (which hardly anything supports) to change the starting address giving you a window, it is also a dumb patcher in that if you change the position of something position in a file it sees a "change" rather than a shift. Xdelta and bsdiff do not have the size limit and for the most part shifts do not affect them either which is why they are used for the DS.
Another problem comes with the newer patching types that implement hashing into a patch (it will check to make sure the file you are putting is good and the file coming out is also good), you can usually tell it to ignore the hashing though although it may take going to the command line to do it.

However many hacks work on the internal file system of the files within the DS rom:
small patches like the basic sound hacks (tetris, pokemon, Castlevania POR), cracker's early trainers and some the scene trainers only change files within the rom and so should not need to rebuild it or change the location of anything.
If the hack is simple (as in the case of the simple sound hacks) the the length of the file will not change and if the hacker knows what they are doing they will reinsert the file with something like ndsts instead of rebuilding the entire rom. Note you can usually pad smaller files out to match sizes and then insert using this method.
This is not always the case though and some choose the rebuild the rom (which has another set of problems as various rom/flashcart combination do not get along with ndstool which DSLazy and DSbuff use to manipulate the file systems of DS roms), mario kart is the classic example and 99% of the time when the basic undub procedure fails (basic procedure is grab sound files from Japanese rom, replace sound file from US/Eu release with Japanese one and rebuild) it is because of this problem.

If it is a basic patch using something like ndsts or ndshv such as the sound hacks you can usually stack as many of these as you please. Note that just because you can does not mean you should: trainers and sound hacks could well use the same things and interfere with each other.

There is also another method whereby you extend the size of the rom beyond what it normally is (trimming roms just gets rid of junk space and you can reclaim this junk for your hack). For the most part this sidesteps the problems with ndstool based operations (at the cost of wasted space) and allows you to change file sizes without rebuilding the rom. Aside from some of my internal testing and that of a few others I do not know anyone that has done this to an actual rom hack released to the "general public" on the DS but I have seen it a few times for internal files, on the GBA there was a problem with earlier scene intros that did just this which meant roms could not be trimmed (a 32 megabyte card could well cost over $100 back when: roms were up to 32 megabytes, average was 8 to 16).

Translation patches and bigger changes may well change the file sizes (pointers are simple and space is near enough unlimited so people tend not to have space constraints like in the older systems) and so the file system will be rebuilt.

Knowing this you can bypass some of the problems or work around it. If for example you want to apply a trainer to a rom and a translation patch apply the trainer first as it should not touch the rest of the rom and it will likely be a dumb patch of some form and when the translation rebuilds the rom you can get the best of both worlds.
On the other hand you can reverse engineer the rom hack and find which files are changed before reassembling a hack of your own.

Adding into this is the patching used by GBA slot cards when running DS roms, often they expect clean roms and so you have to be very careful when patching them usually this patching is done last though and hackers will know this. It also has the effect of changing positions for some things which can make the dumb patching methods (IPS and the like) fail.

 

[Lockon Stratos]

To expand on what psycoblaster said.
You will have to understand how things work with the DS and how patching mechanisms work.
All known commercial DS roms use the nitrorom file system and all I have ever seen use their own file types underneath that. These file types are what makes DS rom hacking easier and harder at the same time (easier as you do not have to worry about space and harder as tracing (a method by which you can determine what does what with extreme accuracy) is nearly impossible.

Patching mechanisms also vary, some of the more modern ones like deufeufeu's patching system and my earlier work with batch files and rom ripping rely on the fact the DS file system exists.

Others like IPS, bsdiff and xdelta work simply by having an address (or three) and replacing the information at the address with the data they hold. It gets far more complex in that IPS has a limit of 16 megs unless you use the hack (which hardly anything supports) to change the starting address giving you a window, it is also a dumb patcher in that if you change the position of something position in a file it sees a "change" rather than a shift. Xdelta and bsdiff do not have the size limit and for the most part shifts do not affect them either which is why they are used for the DS.
Another problem comes with the newer patching types that implement hashing into a patch (it will check to make sure the file you are putting is good and the file coming out is also good), you can usually tell it to ignore the hashing though although it may take going to the command line to do it.

However many hacks work on the internal file system of the files within the DS rom:
small patches like the basic sound hacks (tetris, pokemon, Castlevania POR), cracker's early trainers and some the scene trainers only change files within the rom and so should not need to rebuild it or change the location of anything.
If the hack is simple (as in the case of the simple sound hacks) the the length of the file will not change and if the hacker knows what they are doing they will reinsert the file with something like ndsts instead of rebuilding the entire rom. Note you can usually pad smaller files out to match sizes and then insert using this method.
This is not always the case though and some choose the rebuild the rom (which has another set of problems as various rom/flashcart combination do not get along with ndstool which DSLazy and DSbuff use to manipulate the file systems of DS roms), mario kart is the classic example and 99% of the time when the basic undub procedure fails (basic procedure is grab sound files from Japanese rom, replace sound file from US/Eu release with Japanese one and rebuild) it is because of this problem.

If it is a basic patch using something like ndsts or ndshv such as the sound hacks you can usually stack as many of these as you please. Note that just because you can does not mean you should: trainers and sound hacks could well use the same things and interfere with each other.

There is also another method whereby you extend the size of the rom beyond what it normally is (trimming roms just gets rid of junk space and you can reclaim this junk for your hack). For the most part this sidesteps the problems with ndstool based operations (at the cost of wasted space) and allows you to change file sizes without rebuilding the rom. Aside from some of my internal testing and that of a few others I do not know anyone that has done this to an actual rom hack released to the "general public" on the DS but I have seen it a few times for internal files, on the GBA there was a problem with earlier scene intros that did just this which meant roms could not be trimmed (a 32 megabyte card could well cost over $100 back when: roms were up to 32 megabytes, average was 8 to 16).

Translation patches and bigger changes may well change the file sizes (pointers are simple and space is near enough unlimited so people tend not to have space constraints like in the older systems) and so the file system will be rebuilt.

Knowing this you can bypass some of the problems or work around it. If for example you want to apply a trainer to a rom and a translation patch apply the trainer first as it should not touch the rest of the rom and it will likely be a dumb patch of some form and when the translation rebuilds the rom you can get the best of both worlds.
On the other hand you can reverse engineer the rom hack and find which files are changed before reassembling a hack of your own.

Adding into this is the patching used by GBA slot cards when running DS roms, often they expect clean roms and so you have to be very careful when patching them usually this patching is done last though and hackers will know this. It also has the effect of changing positions for some things which can make the dumb patching methods (IPS and the like) fail.

Uuhh, I'll read it a bit later but thanks fro detailing it!

 

[anime4ever]

you should read it
he spend a lot of time writing it
or maybe he copy it form one of his of hes other post

still he spended time on it

If youl have the .sav you could always re download the rom and patch (or it does not work)
but maybe that's not the case.