.scr text file compression

[Timrulezzz]

Hi, I'm new to ROM hacking and looking into translating Clamore: Gingan no majo since I can't find an English patch online.
I can look into the .nds file using Tinke and suspect that the text for the game is stored under script as .scr files. When I open these using Tinke it shows me random characters which I think could mean the file is compressed. Is there any way for me to uncompress them, then edit and recompress them so I can translate the text? Thanks in advance for any help and or tips ^^

[Bunkai]

Have you tried a relative search?
Is it some address used during the load of the routine you found in the debugger?

Or why do you think the text is there?

Random characters, can be code or any other asset. Doesn't have to be always compressed text.
[In fact compression and that stuff usually means it follows a pattern]

[Timrulezzz]

That's the thing I am not entirely sure what I am looking for. I saw online that there are some common extensions that the textfiles may have (those being .txt .dic .tbl .scr .narc .arc .msbt .bin .nscr) I didn't find any of those (aside from .nscr but Tinke classifies those as map files and the text inside also is not of the readable kind so I think the list of extensions may not be correct or not for this game atleast.) This is how the folder structure looks
Do you know what I should be looking for? The only reason I suspect that it's the .scr files is because they are in the script folder which seems logical and Tinke doesn't classify them as a map or anything like that. In fact Tinke doesn't seem to know what they are.

[Pi-Man]

Nope, not compressed. It's encode in Shift-JIS.




I lost my old files. 

https://www.romhacking.net/forum/index.php?topic=13779.msg377583#msg377583

[Timrulezzz]

Ohh I see, what program should I use to edit them?

[FAST6191]

There is not really a program per se.

Crystaltile2 does support it out of the box, and the table supporting hex editors and such like can probably also use https://www.romhacking.net/documents/179/ if you are so inclined.

The trouble will come, as it usually does, with pointers as those will be needing to be handled (game text does not automatically know where things start and end like a document or something, instead it will be governed by pointers which I usually liken to the contents page of a book. Similar results happening to pointers you don't fix as when you add or rip out pages from a book and set your page counting robot to the task with the original contents page data). DS stuff tends to be file level, and many times you can even get it done with a spreadsheet (so many games will end the section with some kind of indicator, search for those indicators, copy the list of results to said spreadsheet and you have a very easy path to the new pointers).

You may also encounter issues with markup and placeholders depending upon the game -- the basic shiftJIS table will try to decode 16 bits at a time, if the game uses an 8 bit or odd multiple thereof to indicate something then it will fail to decode until the next 8 bits puts it back in line.

Similarly most DS games that nominally use shiftJIS will not support basic ASCII text like the full shiftJIS standard your PC will. Most DS games/fonts will support the Roman characters later in the 82?? region of the sjis standard http://rikai.com/library/kanjitables/kanji_codes.sjis.shtml . It might not look the best (such things are an afterthought most of the time, used only for a few parts of the game and thus not worth putting the effort into) but will be a start.

[Timrulezzz]

Thanks for the tips, I can see the text now using Crystaltile. I do have a few questions about what you said:
The pointers you speak of are they a bit like pointers for Javascript arrays?
What's the use of a table exactly? Aren't they just going to do the same for me as Crystaltile already does?

[FAST6191]

I am not overly familiar with javascript arrays but generally are the same thing in most languages, I tend not to find it the easiest jump from something like C pointers and the way they are normally taught to ROM hacking ones but the principle is exactly the same.
I usually note there are three main flavours of pointer in DS games.
1) Standard, so usually starting at the start of the file you have a list of numbers corresponding to the start and/or end of a text section (or sometimes also used as new line, by the DS it had got a bit more automated or in the text stream itself but it is almost the norm in older consoles). You may have to flip them and there could still be extra information buried in there (who is talking for the on screen pictures, any markup that wants to happen...)
2) Offset. Same idea as before but rather than starting counting at the start of the file you count at some point after it, usually after the header or indeed at the start of the text section itself.
3) Relative. A bit of a hangover from older styles of CPU but seen on the DS and thus you will need to know about it. Take the location of the pointer itself and the data it contains (as ever be aware of endianness/potential need for flipping) and add the two together. You will tend to notice this when you have a list of the pointers from the file, and a list from your search the first pointer might line up or be a few out, the next if it is 4 bytes later will be 4 more bytes out, then 8, then 12...

If the text is in the ARM9.bin or an overlay file it might well have pointers be the system memory location. I have also seen maths done upon them (Touch Detective and some aspects of the NSBMD format had me having to do shifts on the data for some reason), and mentioned markup already (the DS NARC/CARC format putting the upper bit high if it wants to indicate a subdirectory -- halves the space range it can cover but rather than 2^32 you have 2^31, or 4 gigabytes and 2 gigabytes respectively. Easy enough to sort by running a Boolean AND with the upper bit set low and everything else set high). Sector addressing you tend not to see on the DS (32 bits being 4 gigs, rather lower than a dual layer DVD so instead sectors are used and whatever remains at the end of a sector is wasted, see also why your PC says size of file and size on disk), though I have had alternating sections of pointers and data in the past which if you were coding a program to handle it probably would be written much the same way.

Tables and CT2 should be the same at the start, the table however can be customised in the event of placeholder*, markup, formatting and whatever else, or if it has some extra custom encodings in (buttons are usually a popular one for this). It was mostly mentioned in case you wanted to use it with a more conventional editor.

*think it costs ???? to stay here for the evening in a RPG hotel where ???? varies between locations. Many games will include that in the text stream as some value, easy enough then to add that value as another character but have it write out as some unique string ("[cost]" perhaps)your insertion table (often the same as the extraction table, but plenty of times not) can then reinterpret back to something the game can handle, but you can write in yourself and have your conventional text editor not complain that there is binary data in the stream.