Of course. I never talked about storing the character data inside that file. That approach wouldn't work for a few reasons:slowbeef wrote:What if the character palette is stored in a completely different place? I mean, when you decompose the ISO, you get a bunch of DPK files - won't your new English have to reside in the same file as the current character data?
From what I was told the character data (strings, text, dialogue, whatever you call it) is stored together with the game's control script (event programming and stuff). There are numerous such files all containing different parts of the game script. The scripting engine processes the script and occasionally gets pointed to a string via an offset (string location relative to the current position of the "cursor"). One could try to reverse-engineer the scripting langage in order to identify the control codes for printing text. This would reveal the string pointers that could be modified in order to match the new string lengths.
I was thinking about something different. You know, the font.dpk could be massively reduced in size in order to make room that might be needed for storing the game script I was talking about above. Just in case the memory originally reserved for the script wasn't enough. You'd basically have to alter the loading routine to store the script at the new location.slowbeef wrote:I guess what I'm getting at, what if the character palette is in font.dpk, but your character data is a different file like data.dpk? Can the text pointers go to a completely different file? I guess it would still be the same issue either way though; you'd just have to find somewhere else to put it.
Anyway, this might not be needed, at all, if the space reserved for the script is large enough. The real issue is identifying the string offsets hidden inside the scripting language (which needs some reverse-engineering) in order to be able to modify them to one's needs.