All of the data is stored within the install file. Normally, this is an encrypted PGD file. In order to change anything, it must be decrypted. It is then a standard CPK file. The problem is that on a real PSP, you cannot just insert a decrypted PGD file and expect the game to run, it won't.
Sword Art Online: Infinity Moment had this exact same problem. This can be fixed, but you have to do some modifications to the EBOOT, to tell the game that it can run with a decrypted install file. I've been trying to find it and fix it, but I am having zero luck with finding anything.
For the time being, it doesn't prevent a translation project. Both PPSSPP and JPCSP will run the game with a decrypted PGD file. But if this can ever be played on a real PSP, it will need to be fixed.
The other problem I am having is with the naming screen. They really didn't design it to work well with half-width text. I'm sure it can be fixed, but at the moment I've hit a brick wall and haven't any idea how to do it.
As a very, very last resort I'd get the full width English looking the same as the half width. But if we want the font from the first game (which is soooo much better than the default font), I'd have to edit the font file and replace the full width font tiles with the half width font tiles, because the full width doesn't use that design.
Sword Art Online: Infinity Moment had this exact same problem. This can be fixed, but you have to do some modifications to the EBOOT, to tell the game that it can run with a decrypted install file. I've been trying to find it and fix it, but I am having zero luck with finding anything.
For the time being, it doesn't prevent a translation project. Both PPSSPP and JPCSP will run the game with a decrypted PGD file. But if this can ever be played on a real PSP, it will need to be fixed.
The other problem I am having is with the naming screen. They really didn't design it to work well with half-width text. I'm sure it can be fixed, but at the moment I've hit a brick wall and haven't any idea how to do it.
As a very, very last resort I'd get the full width English looking the same as the half width. But if we want the font from the first game (which is soooo much better than the default font), I'd have to edit the font file and replace the full width font tiles with the half width font tiles, because the full width doesn't use that design.
At least you managed to find the problem with the PGDs, I wonder if it uses a standard sony function. It might be possible to use an old version of PPSSPP or JPCSP which doesn't work correctly to find the execution it hangs on.
And the naming screen is weird, it seems to use full width chars normally and then half width for the selected row.
And the naming screen is weird, it seems to use full width chars normally and then half width for the selected row.
The characters on the keypads for the naming screen, they are stored in a file in the CPK (ev_scn_c00_000.pak). The English alphabet is, anyways. Then there is another file within that .pak called kanji.bin that seems to hold all of the Japanese characters for the naming screen.
Because I changed the text routine for the double byte, the game now reads one byte at a time instead of two at a time. The keypads on the naming screen use the same text routine. The problem is that it still wants to display two bytes for each keypad.
If I put 0x41 and then 0x42, the game will put A and B on the same keypad, rather than A on the first and B on the second.
If I put 0x00 and then 0x41, followed by 0x00 and then 0x42, the keypads will be blank and not work, because the game doesn't want a null byte there.
If I put 0x41 and then 0x00, followed by 0x42 and then 0x00, the letters will show on their keypads but only keypad A will work.
If I put 0x41 and then not a null byte but not one that is used by a font character (such as 0xFF or 0x01) it will work, but it will add the 8 pixels spacing between the characters because the game considers it as text and the routine makes it take up that space on the screen. So you end up with A B C D, which defeats the purpose of even using the half width characters.
If I change the text routine, I can get half width working properly on the naming screen, but it screws it up elsewhere.
I've tried un-breaking the double byte and looking for a width instruction for the half width. I haven't found it. I can only find it for the full width.
Call it a derp moment or whatever, but until you said this I hadn't checked the instructions in that spot with the original EBOOT.
But thanks to you saying this, it made me look and yes, now I know how the widths for both full and half width characters are decided.
lw where you replaced it with a li. The lw read 4 bytes from the address in the register. The 4 bytes was 0F 00 00 00 which made it have the 15 pixels width. By changing it to li you ignored that value and forced it to be 8 pixels wide.
The 4 byte value is stored before the first instance of the current text in the memory. I'm not sure where it is stored in the files. I haven't been able to find it and I'm not sure it matters, because we can force it to whatever size by using li instead. There could be unforeseen problems in other areas of the game that I haven't had the chance to look at, but we'll see.
Anyways, using this info I looked to see where the half width text routine did the same. It was further down, but I found it. This means we can now have proper half width English without screwing up the full width characters.
Glad you managed to do it. It's my fault for doing it the bad way, originally I was trying to trace the value back but I gave up since the value seems to get passed a lot, for some reason it didn't occur to me to search though the RAM.
Edit: No idea where the PGD is loaded and but it seems the decrypt key
"d41d8cd98f00b204e9800998ecf8427e" is stored in the eboot at 0x1BA650 (around 0x089BE5B0 in RAM).
Strangely it doesn't seem to get hit by memory breakpoints.
Edit: No idea where the PGD is loaded and but it seems the decrypt key
"d41d8cd98f00b204e9800998ecf8427e" is stored in the eboot at 0x1BA650 (around 0x089BE5B0 in RAM).
Strangely it doesn't seem to get hit by memory breakpoints.
I'm not even sure where the value is stored, I can't seem to find it in any of the files.
And I have to re-fix the space character because the fix that I did, it broke some of the important control codes that use # to begin.
Alright, so I found where the instruction was outputting the character width to the memory. I changed that to a load immediate 0x8 and now full-width, half-width, and the space character are 8 pixels wide with just one instruction change, instead of 3. Plus, this doesn't break any control codes for the script.
What I need or want to do now is find a way to take all of the half-width English font tiles and use them to replace the font tiles for the full width English. Because the font from the first game does not use the same style for the full-width. If I can do that, the character naming screen can use full-width English and the player won't even tell the difference.
I'd also like to remove the Japanese characters from the naming screen. For the official localization of the first game, basically they removed the Japanese character tabs and bumped the English one to the top. Not sure how hard this will be, but I want to at least try.
@ JamRules: Did you ever figure out how to allow more letters in the character names? If this goes the route of using full-width character names, it'll need at least 16 bytes space for both the first and last name, as well as the nickname.
But anyways, while I'm still going to be working on the naming screen, I think I'm going to shift my focus over to text dumping/inserting now that the font is basically fully fixed. That way the actual translation can start.
What I need or want to do now is find a way to take all of the half-width English font tiles and use them to replace the font tiles for the full width English. Because the font from the first game does not use the same style for the full-width. If I can do that, the character naming screen can use full-width English and the player won't even tell the difference.
I'd also like to remove the Japanese characters from the naming screen. For the official localization of the first game, basically they removed the Japanese character tabs and bumped the English one to the top. Not sure how hard this will be, but I want to at least try.
@ JamRules: Did you ever figure out how to allow more letters in the character names? If this goes the route of using full-width character names, it'll need at least 16 bytes space for both the first and last name, as well as the nickname.
But anyways, while I'm still going to be working on the naming screen, I think I'm going to shift my focus over to text dumping/inserting now that the font is basically fully fixed. That way the actual translation can start.
I haven't figured out the memory yet, at the moment the names are stored currently using 8 bytes with 4 blank bytes,
since names are read until null changing the limit to 5 might be possible but not overly useful.
Saved at:
0x094F88D0 <-- name 1 (given) (right)
0x094F88DD <-- name 2 (family) (left)
0x094F88E8 <-- nickname
0x094F88F5 <-- moves to character select if not null
I'm having to two main problems, one the memory locations need spreading out and possibly a bigger problem is at one point (around execution 089A23B4) the whole chuck seems to be saved using multiple words. Since it's not looped there may be the need for more instructions to save larger sizes.
Though, getting rid of the Japanese and making it save the names as half width could allow 10/11 characters and may be easier than trying to alter the storage in memory.
The input limit can be changed by changing immediates at these executions
0888FF10
08891A08
08891A10
08891A14
0888FDE0
0888FDEC
Anyway I think your right to focus on the text side since while the naming would be nice it's not essential
Just a quick update for those actively watching the progress of this, I've gotten the script dumper fairly close to being done. My tool is successfully dumping the text from the file with the script from the beginning of the game, which this file is the second largest script file. The text, when dumped, makes a txt file that is about 331kb in size (which you can guess is fairly large for a purely text file).
What's making it take so long is that the pointers for the text (for those unfamiliar with the term, it's a number (address) telling the game where to look in the file for a specific text string) are scattered throughout the file and it's not just text in the file, but plenty of other stuff that needs to be left alone. Some text strings have multiple pointers, but usually only one is the actual pointer. And some text strings seemingly have no pointer (either they are dud text that the developer decided not to use but never removed or they are using another format for their pointers, which seems doubtful).
I'm going to start looking at the general text (items, menu text, etc.) soon and once I get that stuff dumped, I'll start looking for translators and this project will start for real.
Edit
The items text file seems to use a repeating byte jump pattern that goes:
92-bytes
48-bytes
48-bytes
40-bytes
repeat...
I've got to check the other general text files, but this type of pointer format is quite easy to dump/insert, so that's some good news. As for if we end up needing more bytes than what is allotted by default, I'll have to find where it's calculating the pattern and change it, but it's already a comfy amount of space so it might not be needed.
Edit 2
Alright, I've gone through and made note of (I think) all of the files that have text from the CPK.
I also went through the EBOOT and made note of where the text is located and I've figured out the pointer system for the EBOOT. It's a little bit weird, but nothing difficult.
And from what I can tell, the text in the script files that I said appear to have no pointers, they seem to be in the EBOOT and maybe a few of the other files. So it's seeming like I was right, the text with no pointers is unused text that the developer moved elsewhere and then didn't clean up the trash left behind.
There is also a good deal of image-based text, located in the .tex files. I'll have to research these more, but I'm assuming they will need a tool programmed to convert to png and then back again. I don't really have experience in that area, but one thing at a time. Let's get the plain text part done, first.
The next step is I need to go through all of the files with text and I need to document how their pointers work, so that I can then get my tool working with them. Because there appears to be at least a few different setups for files with text.
What's making it take so long is that the pointers for the text (for those unfamiliar with the term, it's a number (address) telling the game where to look in the file for a specific text string) are scattered throughout the file and it's not just text in the file, but plenty of other stuff that needs to be left alone. Some text strings have multiple pointers, but usually only one is the actual pointer. And some text strings seemingly have no pointer (either they are dud text that the developer decided not to use but never removed or they are using another format for their pointers, which seems doubtful).
I'm going to start looking at the general text (items, menu text, etc.) soon and once I get that stuff dumped, I'll start looking for translators and this project will start for real.
Edit
The items text file seems to use a repeating byte jump pattern that goes:
92-bytes
48-bytes
48-bytes
40-bytes
repeat...
I've got to check the other general text files, but this type of pointer format is quite easy to dump/insert, so that's some good news. As for if we end up needing more bytes than what is allotted by default, I'll have to find where it's calculating the pattern and change it, but it's already a comfy amount of space so it might not be needed.
Edit 2
Alright, I've gone through and made note of (I think) all of the files that have text from the CPK.
I also went through the EBOOT and made note of where the text is located and I've figured out the pointer system for the EBOOT. It's a little bit weird, but nothing difficult.
And from what I can tell, the text in the script files that I said appear to have no pointers, they seem to be in the EBOOT and maybe a few of the other files. So it's seeming like I was right, the text with no pointers is unused text that the developer moved elsewhere and then didn't clean up the trash left behind.
There is also a good deal of image-based text, located in the .tex files. I'll have to research these more, but I'm assuming they will need a tool programmed to convert to png and then back again. I don't really have experience in that area, but one thing at a time. Let's get the plain text part done, first.
The next step is I need to go through all of the files with text and I need to document how their pointers work, so that I can then get my tool working with them. Because there appears to be at least a few different setups for files with text.
Just a quick update for those actively watching the progress of this, I've gotten the script dumper fairly close to being done. My tool is successfully dumping the text from the file with the script from the beginning of the game, which this file is the second largest script file. The text, when dumped, makes a txt file that is about 331kb in size (which you can guess is fairly large for a purely text file).
What's making it take so long is that the pointers for the text (for those unfamiliar with the term, it's a number (address) telling the game where to look in the file for a specific text string) are scattered throughout the file and it's not just text in the file, but plenty of other stuff that needs to be left alone. Some text strings have multiple pointers, but usually only one is the actual pointer. And some text strings seemingly have no pointer (either they are dud text that the developer decided not to use but never removed or they are using another format for their pointers, which seems doubtful).
I'm going to start looking at the general text (items, menu text, etc.) soon and once I get that stuff dumped, I'll start looking for translators and this project will start for real.
Edit
The items text file seems to use a repeating byte jump pattern that goes:
92-bytes
48-bytes
48-bytes
40-bytes
repeat...
I've got to check the other general text files, but this type of pointer format is quite easy to dump/insert, so that's some good news. As for if we end up needing more bytes than what is allotted by default, I'll have to find where it's calculating the pattern and change it, but it's already a comfy amount of space so it might not be needed.
Edit 2
Alright, I've gone through and made note of (I think) all of the files that have text from the CPK.
I also went through the EBOOT and made note of where the text is located and I've figured out the pointer system for the EBOOT. It's a little bit weird, but nothing difficult.
And from what I can tell, the text in the script files that I said appear to have no pointers, they seem to be in the EBOOT and maybe a few of the other files. So it's seeming like I was right, the text with no pointers is unused text that the developer moved elsewhere and then didn't clean up the trash left behind.
There is also a good deal of image-based text, located in the .tex files. I'll have to research these more, but I'm assuming they will need a tool programmed to convert to png and then back again. I don't really have experience in that area, but one thing at a time. Let's get the plain text part done, first.
The next step is I need to go through all of the files with text and I need to document how their pointers work, so that I can then get my tool working with them. Because there appears to be at least a few different setups for files with text.
TwT Finally, good luck
This is likely the case, Sol Trigger had a lot of unused lines like video cutscene subtitles that were never added and even had some stuff which seemed left over from Final Promise Story their previous game. Great work, looks like your making good progress.
The translation hasn't started yet. I am currently dumping the text from the game and then in the next day or two I will be contacting a few potential translators. If they get on board with the project, then the translation will actually start.
Oh and, talking about dumping text, I just finished dumping all of the non-script text from everywhere except the EBOOT and I have it in a Google Spreadsheet. That means I need to dump the text from the EBOOT and finish the script dumping part of the program. The only text after that will be image-based.
Well, I can't give accurate numbers for the script, because the game has some general text mixed in the same files as the script. But I dumped the text from just one of the script files and that has 9493 lines of text. So yeah, it's going to be a lot.
Edit
The EBOOT text is now dumped. I still have some changes to make for the script dumper for it to be 100% operational, nothing too big though.
After that, I'll get re-insertion working. I focused on dumping first so that we can actually get the translating started.
And then the image conversion... which should be interesting.
I'm getting ready to contact some people about possibly filling the translator spot(s).
Edit 2
I've made a new thread here: http://gbatemp.net/threads/in-progress-fate-extra-ccc-translation-project.366533/ for the actual translation project. I'll be posting any future updates in there.
Amazing tehnical progress here. Who will be doing the translating though? It looks like it will be a long project.
Oreimo times 4, this could possibly one of the largest translation project on the PSP.
I would like to offer my assistance if needed, I speak/write English and I am a programmer. If interested, please sent me a personal message and I can further describe my skills. I appreciate what ya'll are doing, very impressive.
Similar threads
- No one is chatting at the moment.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
@
AncientBoi:
What Network is it on? I wanna see what you guys are talking about. N What time frame is it on? -
-
-
-
-
-
-
-
-
-
-
