It's so easy to find this game already patched, just google it: Nayuta no Kiseki English Patched
Except you need to have an untouched Japanese iso for when a newer version of the patch gets released.
You can't apply new patches on top of a pre-patched partial English iso.
Is it so hard?
Took me all of about 10 seconds to find untouched wow
and by the game if you like it sheesh people
and by the game if you like it sheesh people
What's really sad is those people uploading the pre-patched files will get in more trouble than the people creating the patches. That is why most people request that you not upload a pre-patched game. It makes those who worked on the translation look like a bunch of pirates only wanting free stuff when in all actuality they are just wanting to provide the ability to other to play the game in their native language. I mean it is no secret that it is super easy to find the iso but to promote the distribution of the game in a form that it was not originally intended really will piss companies off. I have never had any problems like a C&D from a company for any games I have put patches out for... but I have seen people who supplied pre-patched stuff get them. Especially when I turned a person in for ripping people off distributing Treasure Hunter G as a legitimate squaresoft english release. So don't download pre-patched games. It really is not hard to do it yourself and most people will try their best to help you with the process of patching.
That's great progress. Because of the silence I was kind of worried, but it seems this project is going really smooth. Thanks for your work so far, flame. 
There is really a lot of progress going on with this project but you would have to go to our forums to see it. But yeah, flame and his team are working super quick on this and doing an excellent job on it.
Dealing with these compressed files, I can get everything to show up in-game. What I can't do is get a stable build.
Image Gallery
What I have been doing is fake-compressing using 00 flag bytes (copy byte). This results in a compressed file that's larger than the original. My analysis of decompression routine.
How can I troubleshoot instability?
What I just did with a test build:
Load save->Open menu->Access cooking/cancel->Access quest/cancel->Access monster info/cancel->Access manual/cancel->Access cooking/cancel
When I cancel that final time, I get the crash. But the operation worked the first time. How do I troubleshoot it? Do I need to compress these files (more) properly?
---------------
EDIT:
Back to the decompression routine.
I am getting stuck around 0x89b10cc. s4 says how long to run-length copy. So why is it loading the input size and adding s4 to it? Is base+0x60 not really the input size? During loading of flag bytes, 2 gets added to the input size, which makes sense. You would want to add s4 to the output size. It does this later at 0x89b11cc.
Does this variable not matter? It keeps track of it, and then never uses it for anything (within this routine, not sure about outside it).
Image Gallery
What I have been doing is fake-compressing using 00 flag bytes (copy byte). This results in a compressed file that's larger than the original. My analysis of decompression routine.
How can I troubleshoot instability?
What I just did with a test build:
Load save->Open menu->Access cooking/cancel->Access quest/cancel->Access monster info/cancel->Access manual/cancel->Access cooking/cancel
When I cancel that final time, I get the crash. But the operation worked the first time. How do I troubleshoot it? Do I need to compress these files (more) properly?
---------------
EDIT:
Back to the decompression routine.
I am getting stuck around 0x89b10cc. s4 says how long to run-length copy. So why is it loading the input size and adding s4 to it? Is base+0x60 not really the input size? During loading of flag bytes, 2 gets added to the input size, which makes sense. You would want to add s4 to the output size. It does this later at 0x89b11cc.
Does this variable not matter? It keeps track of it, and then never uses it for anything (within this routine, not sure about outside it).
Here is Patch 3.04 with the following changes:
-The main improvement is it now has "system text" (various recurring events) translated and also the museum sub-areas translated (previously: not translated)
-Changed achievements to trophies
-Game name is now "Nayuta: Endless Trails" (in XMB)
-Save files show the game name: "Nayuta: Endless Trails." Old saves still work.
-Also certain objectives are now translated (previously: not translated)
--Objective text is loaded from the save file. English (if not already present) will not show up until you hit the next objective in your game.
-A crashing bug during a certain event in Chapter 3 of the second playthrough has been fixed
I am having lots of trouble hacking the rest of this game.
The initial offset to the red item varies with the file: pc.tbb is 0x23 and all of fldlist0,1,2,3,monslib,questlib,foodarea,helplib are all 0x1F.
Other files in the ROM are packed with this method too. It varies for each file.
In memory when the compression routine is running is all file content from the orange entry forward.
Red: Word that says how far from the end of the word to the end of the file.
Orange: Says how big the file should be when it's unpacked. Used in the decompression routine.
Green: Unknown
L. Blue: Says how far it is from the point one byte after the end of the half-word (start of message) to the point 5 bytes before the end of the file.
NOTE: Does not hold true for very big files. This means monslib and questlib.
Dark Blue: Always a zero byte
Purple: Start of message. The byte containing the first 8 flag bits.
Brown: Start of message. First non-flag byte.
I wrote a decompression routine: pastebin.com/BWjiYb80
My analysis of the decompression routine.
It will correctly decompress the smaller files, but not monslib or questlib. You have to specify the address of the orange entry in your file for it to work.
The problem with monslib and questlib: it will output a file that looks correctly decompressed, but the output stops at address 0x7FF0 (and it should be longer than that). The problem is the same for both files. You can see in the screenshot above that questlib should be 0x868C when fully unpacked. I'll have to investigate.
So that's the trees.
The forest is:
1) I tried fake compressing the text files.
1a) Actually, the smaller files worked rather well. Maybe I shouldn't try to fake compress the two large files (monslib and questlib) (because I don't understand how their decompression works) and see how that goes as a test. Because in my latest test, the fldlist files worked rather well with no crashes.
1b) When I fake compressed all the files and inserted them, it resulted in an unstable game. So I can't release something like that.
1c) Need to figure out how decompression of the large files works so they can be inserted, too.
2) Maybe if I try correctly compressing the files to reduce their size, it will make the game more stable.
2a) Will need to write a compressor after I figure out the decompressor.
3) I have a problem with .arb files too. My current goal is the text files mentioned above: pc,fldlist0,1,2,3,monslib,questlib,foodarea, and helplib.
------------------
EDIT: The green above is "number of chunks."
It's from a bigger file, so there are three chunks. At the end of the first chunk there is:
Byte 01
Halfword: length of next chunk
Zero byte
First flag byte of this chunk
First non-flag byte of this chunk
There's a kind of "null chunk" at the end (those five bytes) that doesn't contribute to the message.
Now to work this into the fake compression program somehow...
-The main improvement is it now has "system text" (various recurring events) translated and also the museum sub-areas translated (previously: not translated)
-Changed achievements to trophies
-Game name is now "Nayuta: Endless Trails" (in XMB)
-Save files show the game name: "Nayuta: Endless Trails." Old saves still work.
-Also certain objectives are now translated (previously: not translated)
--Objective text is loaded from the save file. English (if not already present) will not show up until you hit the next objective in your game.
-A crashing bug during a certain event in Chapter 3 of the second playthrough has been fixed
I am having lots of trouble hacking the rest of this game.
The initial offset to the red item varies with the file: pc.tbb is 0x23 and all of fldlist0,1,2,3,monslib,questlib,foodarea,helplib are all 0x1F.
Other files in the ROM are packed with this method too. It varies for each file.
In memory when the compression routine is running is all file content from the orange entry forward.
Red: Word that says how far from the end of the word to the end of the file.
Orange: Says how big the file should be when it's unpacked. Used in the decompression routine.
Green: Unknown
L. Blue: Says how far it is from the point one byte after the end of the half-word (start of message) to the point 5 bytes before the end of the file.
NOTE: Does not hold true for very big files. This means monslib and questlib.
Dark Blue: Always a zero byte
Purple: Start of message. The byte containing the first 8 flag bits.
Brown: Start of message. First non-flag byte.
I wrote a decompression routine: pastebin.com/BWjiYb80
My analysis of the decompression routine.
It will correctly decompress the smaller files, but not monslib or questlib. You have to specify the address of the orange entry in your file for it to work.
The problem with monslib and questlib: it will output a file that looks correctly decompressed, but the output stops at address 0x7FF0 (and it should be longer than that). The problem is the same for both files. You can see in the screenshot above that questlib should be 0x868C when fully unpacked. I'll have to investigate.
So that's the trees.
The forest is:
1) I tried fake compressing the text files.
1a) Actually, the smaller files worked rather well. Maybe I shouldn't try to fake compress the two large files (monslib and questlib) (because I don't understand how their decompression works) and see how that goes as a test. Because in my latest test, the fldlist files worked rather well with no crashes.
1b) When I fake compressed all the files and inserted them, it resulted in an unstable game. So I can't release something like that.
1c) Need to figure out how decompression of the large files works so they can be inserted, too.
2) Maybe if I try correctly compressing the files to reduce their size, it will make the game more stable.
2a) Will need to write a compressor after I figure out the decompressor.
3) I have a problem with .arb files too. My current goal is the text files mentioned above: pc,fldlist0,1,2,3,monslib,questlib,foodarea, and helplib.
------------------
EDIT: The green above is "number of chunks."
It's from a bigger file, so there are three chunks. At the end of the first chunk there is:
Byte 01
Halfword: length of next chunk
Zero byte
First flag byte of this chunk
First non-flag byte of this chunk
There's a kind of "null chunk" at the end (those five bytes) that doesn't contribute to the message.
Now to work this into the fake compression program somehow...
I usually have a policy or code that I follow when it comes down to ISOs and ROMs floating on the internet: Yes, while it's convenient as hell to just simply download it, (I might do this occasionally if I just want to try out a game to see what it is like if a demo does not already exist) if I end up liking it enough to play it for an extended period of time or even all the way through it, I try to do right by the company and developers by purchasing it when I can get a good deal on it. Besides, unlike many Falcom import titles out there, this one is probably one of the cheapest ones to import. Most I've seen being sold for around $17. After I started working with Flame on the project doing some of the graphical edits, I felt it was definitely time to purchase my own copy of it and was able to get the LE version for around $27 with shipping included. If you know your way around Japanese sites and can order from Rakuten or BookOff, it's even cheaper than that, like around 100-200 yen for a used copy. If you have a UMD-reading PSP with Custom Firmware, it takes about 2 seconds to put that into UMD/USB Mode and start ripping the UMD directly to your computer to get a ripped copy of your own game to play with and patch to your hearts content.
I guess the point I'm trying to make is that buying it helps the developer and as long as you have a legitimate copy of the game, I really do not think that Falcom cares much what "you" personally do to it as long as you are not distributing the game and that you are not making money off of their intellectual property. Matter of fact, in the days before XSEED, Falcom used to link to NightWolve's website where he hosted English patches for many of the Ys games that he and his team worked on, and I feel that reason was that because of their efforts it led to more sales and more imports from a developer that many of us care about, and there was no problem with that at that point in time. Even I've ordered directly from Falcom in the past. It's fun to order from them and they know how to deal with English-only speaking importers. Now if they could just hire a few to help proofread the English in their games, then they'd be all set!
Anyhow, nice to meet you all and I hope that many of you who enjoy the patch will consider buying a copy of the game!
-Thomas
Came to thank you for working on this, so nice to see that not only 1, but 2 Legend of Kiseki games(I still cant decide if its still just LoH or a new series so I just combined them lol) are being translated
Patch 4.02
Project credits:
flame1234 - project leader, lead translator, lead programmer
SkyeWelse - images
naachan - translation assistance - helped with boss, character and location names
[user]Kelebek[/user] - programming assistance
CUE - programming assistance
[user]zero_g_monkey[/user] - programming assistance (images)
This is not the final patch. Skye is finishing up the tutorial images. That will be the final content for this patch.
There's a problem with the loading screen. But it doesn't seem to affect the rest of the game.
Lots of new stuff this time:
-Skye's images (main menu and world map, not the help screens just yet)
-Quest text
-Monster compendium
-Everyone's names
-Location names
-Food location names
Project credits:
flame1234 - project leader, lead translator, lead programmer
SkyeWelse - images
naachan - translation assistance - helped with boss, character and location names
[user]Kelebek[/user] - programming assistance
CUE - programming assistance
[user]zero_g_monkey[/user] - programming assistance (images)
This is not the final patch. Skye is finishing up the tutorial images. That will be the final content for this patch.
There's a problem with the loading screen. But it doesn't seem to affect the rest of the game.
Lots of new stuff this time:
-Skye's images (main menu and world map, not the help screens just yet)
-Quest text
-Monster compendium
-Everyone's names
-Location names
-Food location names
i tried this new patch version but the game freezes at the initial loading screen and just hear the falcom music logo. The older patches work though.
I use 6.60 PRO-C.
I didn't bother checking the 4.02 version on my PSP though. In my defense, it will run on PPSSPP.
Here is a version with the title screen bug fixed: Nayuta v4.03. I checked this one on my PSP with PRO-C and it loaded at least to the title screen, so hopefully that bug should be fixed.
I didn't bother checking the 4.02 version on my PSP though. In my defense, it will run on PPSSPP.
Here is a version with the title screen bug fixed: Nayuta v4.03. I checked this one on my PSP with PRO-C and it loaded at least to the title screen, so hopefully that bug should be fixed.
Similar threads
