Loading a Translation Patch (Feasibility thread)

[Tempus]

I have been working, along with two others, on a translation patch for the NTSC-J Wii game Zero 4, also known as Fatal Frame 4. At this point, most of the technological hurdles in creating a fully translated game have been overcome, a large chunk of the game is translated, and everything is proceeding smoothly.

Now, while the modified ISO can easily be run on backup loaders, this isn't very useful. I would like to create a patching application which could be run from the newly developed bannerbomb application, for use on a virgin legal Wii.

The idea would be to apply the game patch through some sort of homebrew application. Hopefully, it could be region free at the same time, but this isn't essential. At that point, a completely legal and freely usable translation patch would have been created. Nice.

Is this possible? I do not have extensive experience with homebrew programming, and thus I am looking for highly experienced opinions. If any clarifications are needed on any of these matters, simply post and I will do my best.

I appreciate any replies, and thank you in advance.


The progress thread for the translation can be found: here. Please, no homebrew or loader discussions on the BCL forums, post those here.

[Almas]

I'll reply with what little knowledge I have.

In SSBB, Phantom Wings was capable of finding a method using a prudent ASM insert or two to trick the game into checking an SD card for a file before checking the disk. The primary use for this is changing textures - but in your scenario, it might be usable to change the files which contain the text you're putting stuff into.

If you were able to find a way to make this method work in the game you're hacking, then you'd be able to boot your translated copy through Gecko OS. Of course, to my understanding, Comex' System Menu Exploit currently only works with downgrading and installing applications, but if it does get its usage increased, then it may be possible.

Hope you find this useful.

[Tempus]

That is incredibly useful and just what I wanted to hear.

The bannerbomb is supposed to be able to run any elf or dol file. Your post might be a way to run this patch, and a superior way than my currently considered method (which is to package a copy of the ENTIRE game into the patch, and write a specific SDHD Loader to load that if and only if it detects the game in the disk drive. Not terribly practical).

The goal is to get it to run completely legally, or as close to as possible after all.

[Tempus]

I've received no response from this fellow. Do you know where I could find documentation on his hack?

[Juan]

Or... Instead of using Phantom Wings ASM hack, you could use the new Gecko OS Patch File (.gpf).
I would like to help you with this, but I don't know how to use it, it's very new and only very few people know how to use it.
If you want "instructions" about this:

---------------------------------------------------------------------------------------------------------------------------------

In order to make a GPF (Gecko Patch File) you will need to use a hex editor.  The file should be given named with the game ID and gpf extension and put in a patch folder, that is on the root of your SD card.  Here's the patch file format as described by Nuke:

"[1 byte]   - Number of patches (hex)
[4 bytes]   - Patch Destination (hex)
[4 bytes]   - Patch Size (hex)
[Patch X]   - Patch data size of Patch Size

example

02      - Number of Patches
91000000   - Destination Address
00000002   - Patch Size (this example 2 bytes)
AABB      - The Patch (size of Patch size)
91000004   - next
00000002   - next
CCDD      -

The format will be just a hex blob like this

029100000000000002AABB9100000200000002CCDD

and saved to folder 'patch' on the SD card, with the GameID being the filename with .gpf extension, so for red steel jap, the file name would be REDJ41.gpf placed in folder 'patch'."

---------------------------------------------------------------------------------------------------------------------------------

I take no credits for this, these instructions are in the Gecko OS 1.9 package.
I don't know if it's me or these instructions are almost useless...
Anyway, I'll help you if I find out how to use these patches, good luck.

[Tempus]

No, this is even better than the ASM hack. I'm assuming that this patches the data as found on the iso. With this the case, I can write up a script to make this patch by comparing a modified iso against a regular iso, and exporting all the changes as text. It's essentially a ppf file. Assuming that it works, the only improvement I could possibly think of would be automating the settings and actions of GeckoOS so that the end user need not worry about them, and can merely hit Go.

Thanks a ton! I'll start experimenting.

[Almas]

Patches are a one-time overwrite to a game's ram in a certain location. They do not modify the files on the disk, and if data is ever loaded into the location where you've put a patch, the patch is lost until the game is reloaded.

Phantom Wings has taken a break from Wii RAM Hacking - perhaps I should have noted that. I'm hardly as talented but I may be able to give you some help understanding it some time.

[Tempus]

Ah, so it's not what I hoped for. RAM hacking and translation patches don't seem like the ideal match, from what I can tell. Theoretically I could create the codes, perhaps, but the code file would be well over a gigabyte of addresses and value changes, which may or may not work. Not to mention writing the codes would take ages.

I'm still not certain I can do this. If you happen to have information on Phantom Wings way to read data from the SD, link me to it or post it here.

If you're brainstorming and happen to think of a bold and dangerous plan which just might work, post it up here and I'll give it a shot.

[matt123337]

Ah, so it's not what I hoped for. RAM hacking and translation patches don't seem like the ideal match, from what I can tell. Theoretically I could create the codes, perhaps, but the code file would be well over a gigabyte of addresses and value changes, which may or may not work.

Gpf files can have unlimited lines I beleve... so that would be your best shot.

[Tempus]

The problem is that they're written to the RAM only once at the beginning, correct? And then subsequently overwritten by any following reads from the game disc? Since I'll be wanting to translate every piece of text in the game, theoretically this means that if I load one area, leave, and load it again, the translation would disappear, correct?

Perhaps I'm not understanding the process correctly, though. I'm familiar with hex, but not so much with memory management. I'm still not certain as to the advantages of a gpf patch (which writes only once, and can then be overwritten) versus an Ocarina hack (which continuously modifies values and thus could be potentially be set to replace certain data types with my replacements, through use of a read from SD and extensive checksums). I appreciate any replies.

[Almas]

I think to some extent .gpf files are less useful than originally conceived, because of newer updates to the Gecko program rendering them somewhat unnecessary. But I'll cite an example where I would want to use a patch over a code.

Say, in Mario Kart Wii, I want to change how fast each Kart moves/accelerates to a specific value. One way to do it would be to construct a series of If... cases that identify which Kart is being used, then follow a pointer tree and modify the appropriate value. Similarly, I could use an ASM code to intercept when these values would normally be read, and instead set up Ifs (If Kart is X, take Speed = A instead of its normal value). However, the issue with these codes is that they're cumbersome and long to write, and if I want to change a specific value it can be sort of hard to do at a glance for an inexperienced user.

Instead, I'd set up a table somewhere in unused memory space. The table would be simple: just a three-columned array of Kart || Speed || Acceleration. I'd put an intercept on the location of when the Kart Speed should be read, and instead tell it to scan the list, find the appropriate Kart and pluck out the appropriate value instead of whatever it would do normally. I could use a series of search algorithms to reduce the strain on the system if desired (for example, the Karts will use IDs and if they are sequentially separated, I can use a series of multiplications to get to the correct location in the table instead of searching one by one. But that somewhat irrelevant).

Now, I could write this table using a RAM write to an unused data area (most games have a few pockets of unused space), and then write the ASM code to refer to it. But once the table is written into memory, it does not need to change over time - it is a set of constants. So provided my memory space is truly unused, a single write (and thus a .gpf patch) is all that is necessary. If I am constricted by my line limitation, then it is important that I use these .gpfs rather than use up valuable line space writing things like this.

The fact that we can change where the codelist starts and ends somewhat reduces the need for this, notably. If there is a large pocket of unused memory then I can just write my codes in the first portion and my data tables in the second portion using RAM writes. If you have many small segments of unused space, though, the .gpfs may be needed. If really desperate, you can write ASM codes as .gpfs, too.

I still maintain that a method similar to Phantom Wings' would be the most appropriate for your issue if you did not want to use ISO hacking. But you would have to personally decrypt how the codes work, and try and transfer the result. He originally required a very complex method involving several codes totaling a hundred or so lines, but found an elegant solution which used only about twenty. Perhaps the potential for a similar code exists in your game - it may be the case that the codes which load data from the disk are written very similarly.

[Tempus]

Thanks, that was really clear. I'll look around to see if I can find his codes - if you have a link handy that'd be great too of course. Looks like it'll require a complicated bit of assembly - I'll have to learn more or recruit someone better than myself to make certain it will work. And a gecko. Need one of those too I suppose.

[brkirch]

In SSBB, Phantom Wings was capable of finding a method using a prudent ASM insert or two to trick the game into checking an SD card for a file before checking the disk. The primary use for this is changing textures - but in your scenario, it might be usable to change the files which contain the text you're putting stuff into.

If you were able to find a way to make this method work in the game you're hacking, then you'd be able to boot your translated copy through Gecko OS. Of course, to my understanding, Comex' System Menu Exploit currently only works with downgrading and installing applications, but if it does get its usage increased, then it may be possible.

Unfortunately it probably won't be so simple in this case; the reason Phantom Wings was able to make a code for SD file loading is because SSBB already has functions for reading from a SD card, most games however do not.  That doesn't mean it is impossible though, but it will probably require that SD card reading functions be inserted into RAM somehow and that is not an easy task.

The problem is that they're written to the RAM only once at the beginning, correct? And then subsequently overwritten by any following reads from the game disc? Since I'll be wanting to translate every piece of text in the game, theoretically this means that if I load one area, leave, and load it again, the translation would disappear, correct?

Perhaps I'm not understanding the process correctly, though. I'm familiar with hex, but not so much with memory management. I'm still not certain as to the advantages of a gpf patch (which writes only once, and can then be overwritten) versus an Ocarina hack (which continuously modifies values and thus could be potentially be set to replace certain data types with my replacements, through use of a read from SD and extensive checksums). I appreciate any replies.

It really works in almost the reverse of how you think it does; it isn't necessarily a problem if the data from a GPF (Gecko Patch File) is overwritten after being put in memory because you can setup an ASM insert to transfer the data to memory dynamically allocated for it before that happens.  On the other hand codes have to be put into contiguous memory that will never be overwritten - and you can't easily change the location of the code list after the game has started.  A good example of this is the GPF that I developed for Super Mario Galaxy (see the end of the first post in this topic).

As for what method to use to patch a game with your translation, it will really depend on how big the translated files are.  Text patching would be easy and probably won't be a problem; a GPF will easily work for that.  The graphics are the real problem, so depending on how big those are you might be able to use a GPF or perhaps you will need a SD loader.  Currently creating a SD loader might be quite difficult, however I was considering doing some work on that anyway because I need it for other purposes (so I might eventually make a generic SD loader that is usable for all or most games/channels).

[REDSOXROX]

Ah, so it's not what I hoped for. RAM hacking and translation patches don't seem like the ideal match, from what I can tell. Theoretically I could create the codes, perhaps, but the code file would be well over a gigabyte of addresses and value changes, which may or may not work.

Gpf files can have unlimited lines I beleve... so that would be your best shot.

I think they just add alot, 8191 if I remember correctly from a screenshot

[Tempus]

Very good info, brkirch, and thanks for responding. Unfortunately, it doesn't look terribly promising then, but at least it's doable (which is better than what I've gotten from other areas!). Unfortunately, there is no way this game's text files could be kept as code - the unique raw scripts total 585, 612 bytes - about 5.8 mbs of text. Not only that, but the text is actually kept within a larger structure, as all the game data is kept within RSL files, which are themselves containers for a multi-level nested structure of other files. On top of all that, each script contains a formatting header (4 to 5 times as long as the script itself) and a dynamically pre-generated font image complete with unique character encoding generation, making the whole script likely to be 100 mbs+, even providing we could decode the RAM data and match it to the way the game loads the RSL files and overwrite only the text. If not, a gig, easy.

I know the game contains a method for saving and creating albums - I believe that this writes to the hard drive, though. I'm checking it now, just bear with me for a minute....  Yep, seems to be hard drive. Any more information on how to create this SD loader? Seeing as such a thing would be mostly independent from the actual game code, could it be written in C, compiled, and then the assembly code inserted and modified to work? The community response to an open (but moderated) translation page has been astounding, and provided we finish the batch text insertion program on time it looks like we'll be ready to go to alpha in two to three weeks. The patch here is really the final technological hurdle to break, and I'd like to get working on it if this method is truly possible.