I'm curious what else you've had to hack to account for the moved files. When I've done stuff similar to this in the past, it was quite a pain to get the expanded data to work properly. Did you have to hack a bunch of internal values?
Also, a side question, did you ever find a pointer editor that supports bit shifting? I ran into the same thing- a game with a 6-bit tag tacked onto each pointer. After the tag is extracted, there's a couple more bit-shifts to make everything 32bit aligned. I'm trying to decide the best way to deal with editing these.
I'm not completely sure what you mean, as this is the first time I've exceeded a sector boundary and had to deal with adding an enlarged file to an ISO. PSX-MODE2 handled whatever was needed for the image to account for that. Of course, the new image is still not fully tested, so I'm not positive everything will work.
Unless you mean like the subfiles that make up the the .BIN file that I extracted from the disc? In that case, the answer is the same as for the pointer editor: I brushed up on my Python and created a toolset.
So I do have to hack a bunch of internal values, but the tool that I wrote to reconstruct files from their component files updates the file address/size table automatically. So if the size of one of those files changes, the game still knows where to find the files after it, just like normal.
The script dumper and inserter I wrote deal with the pointers in a similar fashion. I just give them the location range of the pointer table(s), and it bit shifts each value as it's read/written. I dump the script to a text file for editing, then insert it back in. When the inserter writes a text block to the file, the pointer is recalculated from its new position before bit shifting and writing it. That way the pointer values are properly updated. My pointers didn't have tags, though, so I don't know what to do about that. Are they actually tags of some sort, or just 0x00's padding out the 32-bit word?