[owl]

Mizzurna Falls is a 1998 adventure game by Human Entertainment for the original PlayStation.
Over the years it's gathered a fair bit of interest, and notably received a full text translation by ResidentEvie as of December 2016.
Following this translation work, work was started by Gemini on a translation patch, but development stalled around 2018.
Some time last year, an incomplete translation patch was uploaded by another user based on the work that Gemini had made publicly available, but was taken down soon after when it was recognized that this patch didn't address any of the issues that caused development to halt in the first place.

Quietly over the last year plus I've been working on and off on my own translation patch for Mizzurna Falls.
I started work on this patch before Gemini made their work publicly available, and it doesn't make use of any of their work.
The patch I'm including with this thread is more or less a "Beta" version. I've played through the translated game a couple times now, and have
fixed all the major issues I ran into, but due to the open world nature of the game, I can't say for sure that there aren't any issues whatsoever.
Over the next few weeks, I'm hoping people will give the patch a try, and let me know if they come across any glitches or crashes (A note on this later).
Besides bug-fixes, if there are any, I'll be using the beta period to make a few small changes which I'll make posts about when I get around to it.
These are only minor things though, as the current state of the translation patch is about 95% done.

A note on glitches:
The game, even in its un-hacked state, can be a bit glitchy at times, so if you're playing the translated game and see something a bit strange, there's a good chance this is just how the game is, rather than being caused by the patch. These glitches include events not being triggered, animations not playing or appearing broken, among other things. To avoid issues with events not triggering, I'd highly recommend following ResidentEvie's excellent walkthrough for the game: https://gamefaqs.gamespot.com/ps/574993-mizzurna-falls/faqs/71515/.

A note on emulators:
I've tested the game (both translated and untranslated) in a few different emulators, and the only emulator I've found that doesn't cause game-breaking problems is XEBRA (http://drhell.web.fc2.com/ps1/).
NO$PSX has performance issues and doesn't render the minimap, as well as periodically locking the controls for some reason.
EPSXE doesn't render text correctly among other problems, and while Mednafen/Beetle/BizHawk works for the most part, after having the game running for a while, a glitch almost always occurs where parts of the world aren't loaded, and the game crashes shortly after.
I can't speak to whether or not the patch works on real hardware, but this is something I hope to test during the beta period.

MD5 Checksums:
Mizzurna Falls JPN.bin: 36a96b8e813c1f902446f7fed7d88dd3
Mizzurna Falls ENG.bin: 69387b9be4b4681482ad89627c8f5a5f

Things still left to do:
- Minor script changes
- Changing prologue video subtitles from Japanese to English

Patch Download:
The first link is an xdelta3 patch, and the second is an xdelta1 patch. You only need one of these.
https://mega.nz/file/lgBhTCAQ#l5DgDT5zg4Pw6PkEK5t_Uwqu8kcswnsBGEu1mI3lcdk (xdelta 3.0.11)
https://mega.nz/file/IgJnlIpb#jz0IW_0iLgMX2f1zJy7-_i4E8czF27O5McmYRLayiK4 (xdelta 1.1.3)

[manksalot]

Looking forward to try this out, but I'm wondering what patcher I should be using? So far I get an error every time, whether I'm using xdelta UI or commandline, I get "not a VCDIFF input: XD3_INVALID_INPUT." I tried a webpatcher too. My source rom matches the MD5 posted.

[FriedZombie]

+1 unable to patch with Xdelta and getting the same error, seems even if I change the naming scheme _EN and _JP (changing the .cue sheet ofcourse) doesn't really fix anything either.

[owl]

Looking forward to try this out, but I'm wondering what patcher I should be using? So far I get an error every time, whether I'm using xdelta UI or commandline, I get "not a VCDIFF input: XD3_INVALID_INPUT." I tried a webpatcher too. My source rom matches the MD5 posted.

Just updated the OP with an xdelta3 patch, hopefully this one works. Sorry for the trouble!

[nikita600]

Awesome work. And it's kind of funny coincidence, because we want to release our translation patch in 3-5 days or so.

Anyway, I should admit that your patch attempt potentially has one big issue. This files should have size 5300 bytes, because if this files would be bigger than 5300 bytes, you have a problem with game memory manager state. For example, try to call police station on second day and game just freezes, because text file overwrites memory manager state data. Maybe you fixed this issue somehow, but in our patch we just cropped some text data to fit in with memory contraints.

[owl]

Anyway, I should admit that your patch attempt potentially has one big issue. This files should have size 5300 bytes, because if this files would be bigger than 5300 bytes, you have a problem with game memory manager state. For example, try to call police station on second day and game just freezes, because text file overwrites memory manager state data. Maybe you fixed this issue somehow, but in our patch we just cropped some text data to fit in with memory contraints.

Just to clarify, do you mean that the game freezes with the patch that I've provided? If that's what you mean, do you think you could provide steps on how to reproduce the crash? Tried just now but it seemed to work.
As for dealing with files that are too big, I definitely ran into that problem while I was working on this project. I did a couple things to help prevent that, including replacing the shiftjis encoding with something more resembling ascii, and implementing byte-pair encoding for the text files, storing the pairs where the shiftjis dictionary thing is in the original files.

[nikita600]

Just to clarify, do you mean that the game freezes with the patch that I've provided? If that's what you mean, do you think you could provide steps on how to reproduce the crash? Tried just now but it seemed to work.
As for dealing with files that are too big, I definitely ran into that problem while I was working on this project. I did a couple things to help prevent that, including replacing the shiftjis encoding with something more resembling ascii, and implementing byte-pair encoding for the text files, storing the pairs where the shiftjis dictionary thing is in the original files.

Sorry, I didn't test your patch for now. I check files in your patch, because I want to check if there is any "leak" from our team. And, obviously, there us no leak, your patch fully original, but had some potential issue.

What I want to say, is that I speaking about issue with files, that starts from 213 file index, if I remember correctly. You know, this files where only one MDT file and some data in header. These files should have size 5300 bytes (0x14b4). You even patch this constant in you exe file, and it may seems that now game supports files with size 12289 bytes (0x3001), but it doesn't. Game stills expected files with size 5300, because 5300 bytes allocated statically, when game exe was compiled and if we check memory layout, after this 5300 byte buffer goes game memory manager state data. So if game tries to load file bigger than 5300 bytes, game rewrite memory manager state data and then crashed.

I trace this bug a long time ago, when someone on youtube mentioned about this issue. And yeah, I've implemented custom text compression algorithm, that based on Huffman compression and only then we fixes memory issues, but issue with files that bigger than 5300 bytes not. Only Cirosan fixes this issue, just because he rephrases some text entries just to fit in this 5300 bytes.

[manksalot]

Just updated the OP with an xdelta3 patch, hopefully this one works. Sorry for the trouble!

Thanks for the update, got it patched and running now!

[owl]

Sorry, I didn't test your patch for now. I check files in your patch, because I want to check if there is any "leak" from our team. And, obviously, there us no leak, your patch fully original, but had some potential issue.

What I want to say, is that I speaking about issue with files, that starts from 213 file index, if I remember correctly. You know, this files where only one MDT file and some data in header. These files should have size 5300 bytes (0x14b4). You even patch this constant in you exe file, and it may seems that now game supports files with size 12289 bytes (0x3001), but it doesn't. Game stills expected files with size 5300, because 5300 bytes allocated statically, when game exe was compiled and if we check memory layout, after this 5300 byte buffer goes game memory manager state data. So if game tries to load file bigger than 5300 bytes, game rewrite memory manager state data and then crashed.

I trace this bug a long time ago, when someone on youtube mentioned about this issue. And yeah, I've implemented custom text compression algorithm, that based on Huffman compression and only then we fixes memory issues, but issue with files that bigger than 5300 bytes not. Only Cirosan fixes this issue, just because he rephrases some text entries just to fit in this 5300 bytes.

Ah, I see what you're saying. I'd actually forgotten about this since I made the change a while ago, but to solve the problem what I ended up doing was relocating where in memory those files are placed, so now they're loaded into 0x800f8c00 and can be a bit larger than 5300 bytes.

[OldSchoolGamer86]

Has this been tried on actual hardware yet by chance? If not, and if i can get some CDRs ill gladly burn a patch and try it on both on my chipped psx and ps2 and see how it runs.

Regardless...thanks for the work.

[amerika]

I tried this build on real hardware (ps1 5501 model NTSC) that is using an ODE (MODE) and I could not get it past the Sony Playstation splash screen. It will hang on that screen and never boot.

I checked the md5 for the original JP game file and the output after patching it and they matched what was listed above so it was not an image or patching issue.

I can boot the original game without issue and I can also boot the also recently released Cirosan translation effort as well. Kay is in their discord and has been speaking with them. I also messaged Kay on discord.

I do have an PSOne I could use to burn some real discs and test. But I do not believe the ODE is the issue here. I have tried typical MODE troubleshooting as it has an ECC correction feature that can fix a lot of issues some hacks have. But it does not work in this case so it's probably not an ECC issue.

[Cerzel]

Thanks owl, I like this one a lot more than the other one in terms of translation style and font. It's been running fine for me in Xebra so far. I'll report back if I have any issues.

[Masaru]

The underdog translation is really superior to the one pretending to be a localization, incredible.

[ifightdragons]

The underdog translation is really superior to the one pretending to be a localization, incredible.

What's the "underdog" translation?

[Pennywise]

He's talking about this translation, which flew under the radar and is the superior translation to the one on the front page. Basically the other translation wasn't able to overcome the space constraints and had to edit the translation down to fit.

[Zandig]

Tbank you owl, much appreciated.

Testing it out in the latest development build of Duckstation (duckstation-windows-x64-release build).
Played for a bit over an hour and seems good so far. Really atmospheric game which draws you in.

[nikita600]

He's talking about this translation, which flew under the radar and is the superior translation to the one on the front page. Basically the other translation wasn't able to overcome the space constraints and had to edit the translation down to fit.

I must admit, that we was able to overcome the space constraints, but even when I implement Huffman text compression, some files just don't want to compress to fit 5300 bytes. For example, on April/May of 2018, when I finished 1st version on my tools and I inserted original Evie script, using original game text compression alghorithm, I have this issues with memory:


Then I dropped project, because of IRL issues with jobs, and only on August of 2019 I started project once againg and only on May of 2020 I finally have working Huffman compression with variable width fonts rendering. When I repacked same english text data using Huffman, I still can't fit in memory constraints, but this issue was smaller than before, as you can see in screenshot below.


So, as you can see, we should cut some text data only on 7 text files. Other 108 text files we don't need to cut. Because other files fits in memory nicely. And at the end of this project, I've added memory logger for the game, and I found out that, we have about 42Kb+ of free RAM on most memory pressure scenes.