Hacking Possible Summon Night 4 Project

[zero_g_monkey]

Mind sharing your tool for decompressing the text. I have located some pointers in the file "02.DAT". From the way it looks, the .DAT file is actually setup like this. You will see the pointers. There is a table at these locations off the top of my head 0x0000 (Actually the pointer is at 0x38) (first pointer I see) and it points to the location of 0x0368. Another table starts at 0x1000 (0x1004 First pointer in this table)... Here is where it will get tricky. The pointers will be added to the location at which the table starts. Here the first pointer is 0x00B4. But the actual location in the file for this specific dialog is 0x10B4... and so on. There is another set that starts at 0x1800 (0x183C First pointer). First one here is 0x0424. This will take you to the location of 0x1C24.

You can tell so far by where the pointer tables are because there is a number located at 0x0000 (12), 0x1000 (16) and 0x1800 (20). Beyond this point it starts getting messy and I have not had time to investigate it much further and henceforth why I am curious about the decryption tool or what type of encryption it is. I hope this helps out some. AND if something doesn't make sense, I will try to help out as best as I can.


----------------------

Found another table at 0x1D000
and another at 0x21000

 

[Kelebek]

Yes, the archives are aligned to 0x800, so are some sub-files, and other sub-files are aligned to 0x10, and some not aligned at all. You can get the toc of sub-files, but not the whole DAT.

00.DAT you can get all the files for instance. First word is the file count, then some unknowns. File entries start at 0x8 as file pos, file len both as dwords. All the archives list files like that, but the align changes. 00.DAT is all 0x800. The first sub-file in 01.DAT is 0x10 aligned. The first file being listed as 0x3, so it starts at 0x30. You can see it's not the whole file as the 5th file starts at 0x14c30 and is 0x2720 long. Those first 5 files are only 100Kb in total, so that's clearly not the whole 268MB, it must just be one sub-file. The full toc for it must be somewhere else.

Here's what I had for decompressing text though: http://pastebin.com/1XXzvrCF - it's just a complete copy of the MIPS code.

 

[zero_g_monkey]

Maybe in the eboot is the only place I can think of that it could be... unless there is more to those wav files than meets the eye. Now the million dollar question, would the addresses be based off the file allocation table or what. Hmm..

 

[Kelebek]

Yeah I looked at the eboot but couldn't see any sort of list of pointers which could be it. That first file I uploaded there was in 00.DAT anyway, so you can get at it. It's the file entry at 0x230. There's a lot of compressed text files in 00.DAT, but again I don't know how to differentiate between compressed and non-compressed files to automatically extract everything that needs to be. That must be stored somewhere.

 

[SkyBladeCloud]

Is this a port of the PS2 game? If so, then it's a game from the era when programmers knew what they were doing... So it kinda makes for a romhacking challenge: they were pretty creative back then in terms of coding.

I'm not really interested in getting too deep in the technical aspect, like with FFT0 or ToD2 (besides, this must be the first time I hear about this saga ), but if you look closely at those "first 100 kb" you'll realize it's just file system description info, so the rest of the data can be read recursively... Well, besides that text at the beginning... In fact, the actual data starts right after those 100 kb, which in the case of 01.DAT are textures.

About compression, good job, you got it right (I haven't really tested the code but yeah, that's the routine ).

Then there is the text, which is simple shift-jis + pointers, like the decompressed one.

One test:

You can see that I didn't update the pointer (and also that I made a mistake in my own nick! Hell, I'm not reverting everything back again just for that LOL). Actually each line uses a different pointer: at least in the cases I've seen, they don't have a newline character.


~Sky

 

[Kelebek]

Is this a port of the PS2 game? If so, then it's a game from the era when programmers knew what they were doing... So it kinda makes for a romhacking challenge: they were pretty creative back then in terms of coding.

I'm not really interested in getting too deep in the technical aspect, like with FFT0 or ToD2 (besides, this must be the first time I hear about this saga ), but if you look closely at those "first 100 kb" you'll realize it's just file system description info, so the rest of the data can be read recursively... Well, besides that text at the beginning... In fact, the actual data starts right after those 100 kb, which in the case of 01.DAT are textures.

About compression, good job, you got it right (I haven't really tested the code but yeah, that's the routine ).

Then there is the text, which is simple shift-jis + pointers, like the decompressed one.

One test:

You can see that I didn't update the pointer (and also that I made a mistake in my own nick! Hell, I'm not reverting everything back again just for that LOL). Actually each line uses a different pointer: at least in the cases I've seen, they don't have a newline character.


~Sky

I'm not sure what you mean by reading recursively. How do you know the filesizes to be able to do that (to split each texture apart in the case of 01.DAT)? And how would the game know which file it wanted to load? All the SV*.DAT files are just a bunch of RIFFs put together aligned for instance, how would the game access the correct one it wanted if there isn't some sort of toc somewhere? How can you detect which files are compressed and which aren't as well?

 

[Pablitox]

I'm not sure what you mean by reading recursively. How do you know the filesizes to be able to do that (to split each texture apart in the case of 01.DAT)? And how would the game know which file it wanted to load? All the SV*.DAT files are just a bunch of RIFFs put together aligned for instance, how would the game access the correct one it wanted if there isn't some sort of toc somewhere? How can you detect which files are compressed and which aren't as well?

I'm curious of this as well. Also that was a nice pic, I take it there was some way to insert the translated script back? it could be awesome just for script completition.

 

[macaronron]

Sounds confusing.

I wonder how the script files are arranged. Hopefully in chronological order for carrot's sanity.

 

[GHANMI]

Sounds confusing.
I wonder how the script files are arranged. Hopefully in chronological order for carrot's sanity.

At any rate, keeping a list of what each file does (relates to in terms of plot arcs/maps) is going to be helpful

 

[macaronron]

At any rate, keeping a list of what each file does (relates to in terms of plot arcs/maps) is going to be helpful

That's smart and makes sense which is probably why I've never thought of doing it. Though something like that is much easier to do with, say, spreadsheets over a bunch of files pulled up in Notepad++.

I wonder about the images though. A good portion of the gallery is a bunch of background information and references. Also, handling the audio-only lines. Lots of fun stuff for hackers to play with after wrestling with the script, ahaha.

 

[Pablitox]

Sorry for bumping the thread, but here's a bit of extra information, thanks to the user thexyz:

http://bbq.xyz.is/Summon_Night_4

 

[flame1234]

Yes, the archives are aligned to 0x800, so are some sub-files, and other sub-files are aligned to 0x10, and some not aligned at all. You can get the toc of sub-files, but not the whole DAT.

00.DAT you can get all the files for instance. First word is the file count, then some unknowns. File entries start at 0x8 as file pos, file len both as dwords. All the archives list files like that, but the align changes. 00.DAT is all 0x800. The first sub-file in 01.DAT is 0x10 aligned. The first file being listed as 0x3, so it starts at 0x30. You can see it's not the whole file as the 5th file starts at 0x14c30 and is 0x2720 long. Those first 5 files are only 100Kb in total, so that's clearly not the whole 268MB, it must just be one sub-file. The full toc for it must be somewhere else.

Here's what I had for decompressing text though: http://pastebin.com/1XXzvrCF - it's just a complete copy of the MIPS code.

I don't get how to do this. Isn't MIPS just spaghetti code? And spaghetti code isn't supported in Python?
How do you translate unconditional forwards jump (GOTO?) into Python? Am I supposed to translate this into a subroutine and put continue right after it? I get that unconditional backwards jumps can often translate into a while loop.

 

[Kelebek]

I don't get how to do this. Isn't MIPS just spaghetti code? And spaghetti code isn't supported in Python?
How do you translate unconditional forwards jump (GOTO?) into Python? Am I supposed to translate this into a subroutine and put continue right after it? I get that unconditional backwards jumps can often translate into a while loop.

Forward jumps into if elses and backwards jumps into while loops usually. If there's an unconditional jump forwards that all the code doesn't hit, then it means that there's a condition somewhere to get to that code instead of the code below it, and you can make it into an if else. That's why I have so many of them and they extend so far in that code, because that's basically where all the jumps are. It's not really spaghetti, because it's built from high-level code, so it has to represent what the high-level code is written to do after all. If you get good at it, then you can translate the MIPS/ASM/whatever back up into the high-level language and represent the original code, in which case things get a lot cleaner and simpler. I'm awful and can't do that though, so pure copy for me.

When trying to directly copy it like that though, it does certainly get messy, very messy. You end up needing to think about huge logic strings all intertwined which is certainly annoying, but can be done eventually. Essentially what you're doing is just mapping out each possible path that the code can take through the function.

I left all the addresses in my pastebin there, so if you have the game you could follow the MIPS with the python and try see how it works. There's an example of it right at the very start, just under the first while.

 

[EdenLegaia]

Oh boy oh boy oh boy oh boy

I never thought there would be a Summon Night 4! You guys made my day!
Will it be ready someday? Won't it be dropped and the project will slowly die? I don't know, nor do you, but be sure of something: You have my thanks for trying and make the first step!

 

[Pablitox]

Well, luckily carrotpatch is still at it, we are doing another project in the shadows though (more on that when there's been enough progress) in the meantime, we are still loking for hackers.

 

[Pablitox]

in case anyone wanted, here are some caps I took from the iso, using UMDgen:

SYSDIR:

USRDIR:

 

[ObeSeeker]

Ive played this game for 200 hours.

The bug is only on pro c. On me the game works fine. I change to me every time lol. When it first happened I was pissed lol.


Edit:
Haha I came looking for information about the digimon patch. If only sooner...

 

[GHANMI]

@Pablitox Not for this version of SN, but this could be interesting. Hope this could be useful
(hopefully SN3/4 have as much luck with fixing the font... tbh even the GBA localizations never really used a true variable width font, they just changed the fixed width from 12 to 6)

 

[Pablitox]

@Pablitox Not for this version of SN, but this could be interesting. Hope this could be useful
(hopefully SN3/4 have as much luck with fixing the font... tbh even the GBA localizations never really used a true variable width font, they just changed the fixed width from 12 to 6)

Way to go ghanmi, thank you very much.
Hell yeah, tackling SN3 or 4 would be cool, as the 5 one is getting a localization.

 

[Majima]

Since this topic is up and bumped and people visiting the thread are probably interested in the series, I saw that the pre-sale for Summon Night 5 will open on tomorrow (Monday) at http://www.gaijinworks.com/

They plan to make a physical run if there is enough interest in it which I personally think is awesome for a 2015 PSP release. This is likely the last or second to last ever UMD release in America. Every physical copy also comes with a voucher for a legal digital copy from PSN. It will only be printed in enough copies to cover pre-orders so it might be hard or expensive to come across later.