You gotta catch up your new programmer.
Like a lot of games, this game uses a big archive file, and you have tools to extract/insert. Or at least some way of dealing with it. How about sharing those?
You should feel free to share that EBOOT patch based on the decrypted EBOOT if you feel like sharing. Or maybe not, there are a lot of reasons not to share it, too.
Probably pointers are not too complicated but no promises. I worked on ZZT3 (Zettai Zetsumei Toshi 3) which is an IREM game too and we couldn't get text insert to work at all! We figured out the format and put in our modified text, but it just didn't work; I didn't care to troubleshoot further...and our programmer gave up on that one, too.
----------------------------
Isourou, the lead, says the old programmer didn't give permission to share the tool.
No, it wouldn't help to have a dump of the text in the EBOOT. I'll just make that dump myself.
I turns out a lot of the text is in the EBOOT so I'll have to make my own tool. If we want to use the same length as IREM did that won't be hard. If length needs to be changed, then I'm not sure how to proceed. Whenever I expand EBOOTs, it doesn't work on a real PSP, I've never gotten it to work. My strategy has been to find a resident file other than the EBOOT with a fixed location and put the extra data there.
Here's READELF data for the EBOOT:
http://pastebin.com/HjUE94ayLooking at the READELF data, section 20 has strings data in it (maybe other data too).
That section is real big, it's 0x1a2250 bytes = 1.6MB so it's possible that contains all the text. I'm really not too sure.
I see above you need to figure out the pointers, so I'll get to work on that.
---------------------------------
ALL EBOOT strings (reference only, not for translating):
https://docs.google.com/spreadsheets/d/1iZ146s9wuYaNKtf0Ml5HhPwjeFJOe_d6q6Qlu9lc61o/edit#gid=0Spent ~3 hrs cleaning it up. Generic text dump tools have a tough time identifying string boundaries.
Here is the code I used to dump (and then manually clean it up):
http://pastebin.com/QL3y4cgm---------------------------------
EBOOT strings for translating:
https://docs.google.com/spreadsheets/d/1PAS3bHEnJsB9Sl8RROu2FW4OlNTMIdUwkicF4_pGYG4/edit?usp=sharingI need you to PM me your email address for edit access.
Let me see about finding those pointers.
The first string 戦闘機 is at 0x215508 in the EBOOT and 0x08B154B4 in memory, a difference of 0x88fffac.
The first check will be for virtual addresses in that data section that match string locations. If there are any matches, they are pointers, no doubt about it. We need to remember that file address + 0x88fffac = virt address
So the pseudocode is:
1) virt address = file address + 0x88fffac
2) search for virt address and record all matches
Simple, right?
-------------------------
Okay, I wrote this program:
http://pastebin.com/qATbCMTvI found most of the pointers and put them in the sheet above. I'll need your translations to continue at this point.
--------------------------
The start of the first block is 0x215508 the end is 0x222014. That's line 1 through 1337 (purely a coincidence) in the dump.
The first task will be to make sure all the pointer are identified in this block. Next, we're going to relocate every single string based on its translated length to make sure we can reclaim all space from your translations that are shorter than the original. After that is just to see how much extra space we need for this first block. Seems to be ships data.
---------------------------
Good news! In the first block of strings, their translations will take up 49,028 bytes when inserted and there's 51,980 bytes available (computed by 0x222014 - 0x215508). Now just to make sure we have a pointer for every string in this block...
Yep, there's a pointer for every string in there, 1169 of them. Now to write the inserter tool, it shouldn't be too hard.
Here's the pseudocode I will be using:
1. Blank out the block
2. Read our input data, we actually don't even need the address (though it's a key for string identification so that will be useful when reading input data). We need lines and pointer. Address we don't care (because we have all the pointers); it will be computed at runtime.
3. Set starting address 0x215508
4. For each set of lines and pointer address:
4A. Build the string. Encode the lines and put newline characters between, then pad to word aligned.
4B. Update the pointer. The new pointer is equal to current address + 0x88fffac.
...And that's it, EBOOT updated. Not too hard, honestly.
There is a lot of extra space here. It seems like length limits are going to be based on space available in textboxes rather than on EBOOT space.
Topic: R-Type Tactics II (PSP) FULL PATCH RELEASED (Read 79574 times)