Research: Pokemon Mystery Dungeon: Explorers of Time info

[Nerketur]

Updates:

• New format of post!

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

Hi again! I've started another project, though this one is much harder. I'm going to try to figure out scripting in this game (and anything else I can figure out.)

What I have so far is easy enough... After using NDSTOOL to unpack the archive, I started with all those .ssb files in the script folders. And here's what I have so far:

.SSB info:

• Somehow related to other .ss? files. Notable are .sss files which CAN be referenced from it. (As well as other .ss? files, apparently.)
• All message strings are found in these files, plus what I call "constants" (Though these constants are probably simply includes/references.).
• There are exactly four parts, (excluding the file header) Groups, script, constants, and strings
• Scripts use starting point (for goto commands) as word 7.
• Groups seem to change what is loaded onto the screen. Testing is needed.

.SSB format:

Spoiler:

I know all but one word!

Info:

Initial locations and direction facing are NOT contained in here. Rather, it is contained in the .SSA file grouped with this file.
using 0x00FF commands will display the characters associated with that group. (I believe the order is the same as defined in the SSA file)

Header:

The first 6 words of the file are a header.

So, with a file that starts: (in hex)

ccccssss xxxxdddd tttt????

cccc: Number of "Constants"
ssss: Number of "strings"
xxxx: size of script area in words (up until first 'constant')
dddd: size of the data portion of constant table
tttt: size of string table

Script area:

Groups:

A "group" is a number made from 6 bytes. There can be any number of these groups, supposedly; I've even seen 0 groups. (Though this is rare.)
As far as I've seen, if the number of groups is 1, then the bytes in the group are ALWAYS '05 00 01 00 00 00"
If the groups are greater than one, then it seems the '05 00 01 00 00 00'
entry is missing.

The purpose of these groups is supposedly entry locations, so the script doesn't have to always start from the beginning. It is unknown how these are called, though 0x76 allows scripts to continue at a point set by a group. (And this is by a 0-based number.)

I now believe groups are three words. the first is where the entry is, the second, the type, and third, I don't know yet.

Format:
AAAABBBBCCCC

AAAA: location to go to
BBBB: type (0003 = animation when appear)

CCCC: ? (Character when type is 0003)

Script data:

Within this section, the ENTIRE script is found. (Or, most of it. The rest can be found in included scripts, (through the "constants") but I'm unsure exactly how this works.)

Constants:

All are null terminated. Before the constants is a number of words, equal to the number of constants. Each word gives the offset (in bytes) from the beginning of the section to the beginning of that string + numStrings*2.

Strings:

Generally the same as the constants. The only exception is strings can have lowercase letters, and anything else regular strings can contain.

There are special things that can be contained in a string, enclosed in []'s One example is [K], which will cause the user to have to wait for a key-press before continuing with the rest of the string.

Theories:

The ENTIRE script starts with unionall.ssb This one script controls the order the scripts are run in. It also controls what scripts are run, or are not run.

Two things I do know for certain. The information stored is in words. It's a common thing in this file, and as such, certainly expanded scripting from bytes to words. And... All the entrance files (with the same numbers), with a few exceptions, are very similar.
I presume that files like "enterXX.ssb" the XX determines the "type" of entrance it is. I do not know this for sure yet.
Perhaps ASM can be encoded using include scripts? Or maybe (even better) the larger command base (65535 total possibilities) allows for more freedom. Hard to say for sure. I highly doubt that all possibilities are used, though it's possible. This is the second rendition, after all. More memory, longer game

.SSA Info:

• Position data (for 0x00FF commands) outlined in here. All locations (At least for Pokemon. Not sure about objects yet). =D
• The theory that all level changing and understanding of 'level' variables are contained in here is incorrect. However, 0x00FF meaning is contained in here, at least partly.
• This theory could be wrong, however... Unionall.ssb may hold the key instead.

.SSS Info:

• Same format as .ssa
• Seems to be able to be "included" into a .SSB file.

.SSE info:

• Same format as .ssa
• Only enter.sse exists as far as I know.

.LSD info:

• This format is easy. As it seems, all strings in here relate to a SSA/SSB file. They are fixed-size, too. All are exactly 8 characters long, and the first two bytes tell how many strings are in the file.

.LSD Format:

Spoiler:

Header: 2 bytes (One word)

Header tells how many strings are in the file (which are really file names. Each one always has .ssa and .ssb These are NOT null terminated.


Theoretically, there can be any number of files here, (up to FFFF), but 0 would be a waste of two bytes. So, I don't believe there are any of those.

Notes:
It seems that the "enterXX.ssb" are used first, upon entrance to the place/dungeon/whatever. I believe that enter.sse (the only one with an SSE extension) somehow chooses the correct enterXX.ssb
Counterpoint: Not all script folders have one, and not all those that do have multiple enter files.
Counter-counterpoint: It's likely that some were removed later.


I've also noticed that any u?XX.sss files are not in the .lsd file. And in fact, there is NO .lsd file if the folder only has 'enter' and 'u?XX' files. (Apparently would be a waste.)
It seems that all the u?XXXX.ss? files relate to not allowing the hero to go to certain places, or are looping/conditional constructs. (Which I believe is what 0x2B is.)

Current progress:

• -- Assembler equivalent is in the making --
• -- Figuring out how scripts get called and why it doesn't always work --
• Testing .SSA files (On hold)

TODO:

• -- Figure out Sky opcodes --
• Figure out purpose of types in groups. (Partly done)
• Figure out the purpose of 0x74, 0x84, and a few other commands
• Change tool slightly to add ability to change via enter and delete.
• Play through certain scenes to understand the script more.

Other new knowledge:

Numbers seem to work as follows on parameters that are expected to be numbers:

If the word has it's leftmost bit set to 0 (0x0000 - 0x7FFF) then it is a SIGNED 15-bit number. If the word's leftmost bit is 1 (0x8000 - 0xFFFF) then it is a fraction/float. I think it's signed as well..

However, this isn't ALWAYS true.

Certain commands (such as 0x77 and 0xB0) seem to be dynamic sizes. Their size depends on the second word after them. Although it's possible that it's simply a separate command, the same word can mean two different things in 0x77, vs 0xB0.

According to what I found, "77" codes are a seperate deal than b0/b1 codes. All 77 codes have a non-77 counterpart that does the same thing.

For example.... 0077 0000 0130 => 0130

The Pokémon numbers used in scripts are different from the actual numbers. (i.e. 0x38 Zubat, 0x41 Koffing) I haven't looked into it past this, though.

Final remarks:

My tool is a BIG help, albeit hard to use. Once I get more info understood, I'll make it easier to use =D

If anyone would like to help, they are more than welcome to do so. Whether it be research of their own, or figuring out a format. I'd appreciate any info anyone has. =)

As I figure things out, I'll update this thread. And... I'll also update my LeafGreen info thread of all the scripts if I get to working on it again. =P

.SSB files can and do control the order of script execution, as outlined in unionall.ssb. However, this is rarely used, except in unionall.ssb, or to do certain scripts like setting BGM or saving (though these can also be done via script.)

Find my tool here.

[Nerketur]

Quick question for everyone... Since my tool would be mainly for PMD, I'd like to know how much interest there is for this. My goal for this is to create a tool that can look through an PMD ROM and get all the script data from it, in a nice tree format. (Just like it is in the ROM itself) This data can be edited using "assembly" (that I will have to "create") or manually (Assuming you know the raw hex.) This editing will be realtime. Changes to the hex will show up in the assembly, and vice versa.

Basic overview is as follows:
Features:

1. Real-time editing: Hex and assembly changes as you work.
2. Tree structure for scripts
3. XSE-like structure for editing
4. Planned support for all current and future versions of PMD
5. Ability to save custom script fragments.

Other features will be added as I think of them, but would PC like a tool like this? If not, I'll make it anyway, for my own use. =P


Oh... and one other thing. It will be made in C# I might even add Plugin support for expansion, but I really don't know at this point.

Here's a screenie of what I have so far. The GUI is likely to change drastically, however.

Spoiler:

[Team Fail]

If I am correct, the games are based on Blue Rescue Team, so have you tried looking in arm9.bin? There may be some stuff in there you could be looking for.

[Nerketur]

Originally Posted by Team Fail

If I am correct, the games are based on Blue Rescue Team, so have you tried looking in arm9.bin? There may be some stuff in there you could be looking for.

Just now looked into it, and there ARE a few useful things =D The folder names appear to be here, all in a list. There are also some more useful tidbits. I'll have to look into it further. In terms of scripting, I don't think much is in there. The engine itself could be, and given a few things in there (files referenced with a .c extension) I think they programmed the game in C or C++. Or at least portions of it.

As far as scripting itself is concerned, so far, my best bet is looking at all the .ssb files. That said, however... I'll definitely keep arm9.bin in mind.

Right now I'm focusing on PMD: Explorers of Time. It was my own assumption that Blue Rescue Team would follow Red Rescue Team's scripting engine, though I have not yet confirmed this. (I'm also assuming Explorers of Darkness is similar to Explorers of Time AND Sky. This is why I chose Time to start with.)

Still, thanks for the info! =D

[Team Fail]

Originally Posted by Nerketur

Just now looked into it, and there ARE a few useful things =D The folder names appear to be here, all in a list. There are also some more useful tidbits. I'll have to look into it further. In terms of scripting, I don't think much is in there. The engine itself could be, and given a few things in there (files referenced with a .c extension) I think they programmed the game in C or C++. Or at least portions of it.

As far as scripting itself is concerned, so far, my best bet is looking at all the .ssb files. That said, however... I'll definitely keep arm9.bin in mind.

Right now I'm focusing on PMD: Explorers of Time. It was my own assumption that Blue Rescue Team would follow Red Rescue Team's scripting engine, though I have not yet confirmed this. (I'm also assuming Explorers of Darkness is similar to Explorers of Time AND Sky. This is why I chose Time to start with.)

Still, thanks for the info! =D

No problem. And I just remembered, try also looking in the overlay.bin files as well. In Blue Rescue Team, the entire game script was in the overlay files in plain ASCII.

[droomph]

Originally Posted by Team Fail

No problem. And I just remembered, try also looking in the overlay.bin files as well. In Blue Rescue Team, the entire game script was in the overlay files in plain ASCII.

Hey, sorry for posting here about this, but what do the ARM.bin files do?

Originally Posted by Nerketur

Quick question for everyone... Since my tool would be mainly for PMD, I'd like to know how much interest there is for this. My goal for this is to create a tool that can look through an PMD ROM and get all the script data from it, in a nice tree format. (Just like it is in the ROM itself) This data can be edited using "assembly" (that I will have to "create") or manually (Assuming you know the raw hex.) This editing will be realtime. Changes to the hex will show up in the assembly, and vice versa.

Basic overview is as follows:
Features:

1. Real-time editing: Hex and assembly changes as you work.
2. Tree structure for scripts
3. XSE-like structure for editing
4. Planned support for all current and future versions of PMD
5. Ability to save custom script fragments.

Other features will be added as I think of them, but would PC like a tool like this? If not, I'll make it anyway, for my own use. =P


Oh... and one other thing. It will be made in C# I might even add Plugin support for expansion, but I really don't know at this point.

Here's a screenie of what I have so far. The GUI is likely to change drastically, however.

Spoiler:

I would love something like this.

Although I think that you should make an automatic comment on disassembled scripts for the movements.

Like so:
Action for 0000 at type 0123 'moves running
wait animation 0000

Or something crazy like that. But whatever, if you don't want to, I can live with it.

[Team Fail]

Originally Posted by droomph

Hey, sorry for posting here about this, but what do the ARM.bin files do?I would love something like this.

Although I think that you should make an automatic comment on disassembled scripts for the movements.

Like so:
Action for 0000 at type 0123 'moves running
wait animation 0000

Or something crazy like that. But whatever, if you don't want to, I can live with it.

ARM files help provide structure for the game, and provide instruction that other files cannot provide. It varies from game to game. The Pokemon games have camera angles in the ARM files, as well as what song plays under specific battle settings.

[droomph]

Originally Posted by Team Fail

ARM files help provide structure for the game, and provide instruction that other files cannot provide. It varies from game to game. The Pokemon games have camera angles in the ARM files, as well as what song plays under specific battle settings.

And it's all in ARM? Wow that's gonna be a lot of work for someone to look through that.

[Nerketur]

Originally Posted by droomph

Although I think that you should make an automatic comment on disassembled scripts for the movements.

Like so:
Action for 0000 at type 0123 'moves running
wait animation 0000

Or something crazy like that. But whatever, if you don't want to, I can live with it.

I might do that, actually. However, I don't think it'd be that simple. I plan to have it be able to say "(Action) Player moves to (23, 6)" The text is more of a placeholder. Actually, come to think of it... I might make it all one window, and switchable from hex to assembly with a single click. I'll have to think about it.

Oh... and it won't only be movement. Pokepics, Items, everything will be included. I may use the whole @define idea, though. We'll see. =P

[droomph]

Yeah...

I just realized that PMD is based off of Shiren the Wanderer, so you might want to try to look that up too.

[Nerketur]

Originally Posted by droomph

Yeah...

I just realized that PMD is based off of Shiren the Wanderer, so you might want to try to look that up too.

I heard that... but I know nothing about that game, so I'm not sure how it would help. I'm having a lot more progress just looking through all the script files and changing my tool to reflect new knowledge. =)

[ipatix]

Does anybody already know something about te soundengine of PMD Exp. T/D?

Because it seems that the game doesn't use the SDAT file format and the Nitro Composer Kit.

[Team Fail]

Originally Posted by ipatix

Does anybody already know something about te soundengine of PMD Exp. T/D?

Because it seems that the game doesn't use the SDAT file format and the Nitro Composer Kit.

The NITRO Composer Kit? Does that come with the NITRO SDK? Or is it anywhere on the internet? Because I am interested in finding this.

[andibad]

Originally Posted by ipatix

Does anybody already know something about te soundengine of PMD Exp. T/D?

Because it seems that the game doesn't use the SDAT file format and the Nitro Composer Kit.

because is from Procyon Studio Digital Sound Elements not from SDK.

[machomuu]

Originally Posted by droomph

Yeah...

I just realized that PMD is based off of Shiren the Wanderer, so you might want to try to look that up too.

I don't know if it's based off of one specific game. The whole "Mystery Dungeon" genre was pioneered by Torneko no Daiboken: Fushigi no Dungeon, so really any Mystery Dungeon game would suffice. Though, since we're talking DS, it might not be a bad idea to look into the Izuna games.

[Nerketur]

Hi again! I haven't been able to work on this much until today for various reasons, including graduation from College. But that's over and done with now, so all is now good for me to be working on this and hopefully finish it! I'll update the first post with new info soon, as I've figured out a bit more about .SSB files. This is getting interesting. Interesting enough to give a few examples.

Example 1: A simple message from your partner, depending on type.

0092 0004 0000 0000 -- load Pokepic and speaker '4' ("4" refers to your partner character)
009A 003A           -- Checks the partner's type (Only 3 types are known)
    005A 0001 0001  -- If the partner is of type 1, display message 1
    005A 0002 0002  -- if the partner is of type 2, display message 2
    0061 0003       -- if the partner is of any other type, display message 3

Example 2

0092 0004 0000 0000 -- load Pokepic and speaker '4' ("4" refers to your partner.)
0099 0039           -- Checks the player's gender
    005A 0004 0027  -- If the gender is male (4) then display message 0x27
    0061 0028       -- Otherwise, display message 0x28

[Team Fail]

That's a very simplistic scripting format. Perhaps we can try figuring out all the commands by editing a script with a bunch of commands. Perhaps there may be an unused one? Or two?

[Nerketur]

The most complicated is actions. 0x0077 has many different actions depending on what it is, and its size changes depending on what type of action it is. Same with 0xb0, 0xb1, and 0xb2.

Other than those, however, everything else seems to be pretty basic. And that's what I've been attempting to do. Not random ones, but anything I don't know what does, I edit into an early script (on emulator) and see what it does. Some seem to do nothing, like 0x00FE (Beginning of most scripts) and 0x0072 (No idea what this does, but it likely takes 3 parameters.)

And! I figured out something! the .SSA files have the locations of all the displayed Characters =D Still figuring out a few other things, but progress has been made =D

[Nerketur]

News! I think I just hit a breakthrough! I finally got unionall.SSB to run through my program (so it disassembles it) and I think I also realized something. That one file references ALL the other script files that currently run. All the levels, dungeons, etc. All of them exist (by name) as what I call "Constants" (I may rename it to references now) in unionall.ssb Because of this, I think I now understand what happens as far as script flow of the game. So, a new theory:

New Theory: The ENTIRE script starts with unionall.ssb This one script controls the order the scripts are run in. It also controls what scripts are run, or are not run.

What this means, is that all scripts theoretically have this power, and all use it for partner sayings, and interactions. But the ringleader of it all is unionall.ssb, I now believe. Getting more interesting by the minute =D

[Nerketur]

Small little update with huge results. I updated my tool to work with showing exactly where goto commands will lead to, and this has gotten me MUCH better at finding out what things do. The debug menu and tests are a big help as well! Most/all sound related commands are now known, setting dungeon modes known, a few placing commands known, and a bit more about actions known. I might actually release an alpha later this week. Maybe on Saturday. In any case, working on this and getting breakthroughs is awesome =D

[Nerketur]

I'm currently working on fleshing out my current alpha of the tool a bit. I'll be releasing an alpha of it soon, likely within a week! The tool can currently only view script from PMD Explorers of time, though it does attempt to parse Explorers of Sky as well. (It parses incorrectly, however.)

Current features:

• Can read in the entire ROM, and parse the script files inside it.
• Hex (in words) and partial assembly are shown, side by side
• The scroll boxes are set to scroll at the same time.
• The file you are looking at in the ROM is highlighted in the tree view!

Features not fully implemented:

• Loading works fully, saving is not implemented.
• ONLY .SSB files can be parsed, (other than .NDS roms)
• It currently only allows for loading of PMD EoT, and PMD EoS, english versions. Other versions may be possible, but are not supported
• Scrollboxes can get out of sync. If this happens, click either scrollbar, and they will re-sync.

Known bugs (Prone to change closer to release):

• PMD: EoS doesn't parse correctly (I haven't implemented any sort of version check, so it tries to use the same commands as Time, which are incorrect for Sky.
• Scrollboxes get out of sync easily if you use the arrow keys to move around the text boxes. (I may removes the two, and just have one.)
• "reload" in the menu doesn't work. (Not implemented)
• In certain rare cases, if the commands don't parse correctly (or key ones are missing) then the strings and "constants) will get messed up which will prevent the script from loading properly. This is currently only fixable by adding the unknown command to the parser. (Later I may make it so it can safely ignore this and still parse strings and constants properly, but for now it's a bug that I don't care to fix, as it helps me to easily identify problem areas.)

Planned fixes/tweaks before release:

• UI enhancements (Possible merge of the two files.
• Saving possible (Might not do this til later)
• let reload work
• Make it so it closes the file after reading all NDS data from it. (Less annoying that way)
• Fix up the code to work better.

[Kindrindra]

If this seems like a noobie question- well, it kinda is. ._.


Um. I've been trying to figure out the hex in the m_attack.bin file and monster.bin file... but I'm a little lost. I noticed that both Sky and Time/Darkness have a pretty regular pattern of two zeros, then two numbers, then back (Though the pattern does seem to break down later), but... That's about it. I'm guessing that the numbers are things like the move's power and accuracy and suchforth, and the zeros are flags, but I can't find where one move ends and the next begins. ._.

[Nerketur]

Originally Posted by Kindrindra

If this seems like a noobie question- well, it kinda is. ._.


Um. I've been trying to figure out the hex in the m_attack.bin file and monster.bin file... but I'm a little lost. I noticed that both Sky and Time/Darkness have a pretty regular pattern of two zeros, then two numbers, then back (Though the pattern does seem to break down later), but... That's about it. I'm guessing that the numbers are things like the move's power and accuracy and suchforth, and the zeros are flags, but I can't find where one move ends and the next begins. ._.

As for the pattern, it looks like offsets to a different spot in the ROM. The offset being an integer. So each attack has an offset. For example:

00 00 00 00 51 02 00 00 C0 12 00 00

To me, that pattern tells us a few things.

• The offsets take up 4 bytes each
• Given how numbers are stored, and that it's 4 bytes, the numbers are in "reverse" order.
• There SHOULD be the same number of offsetts as "attacks"

So, given that... we know 00000000 (0) is the beginning of the file. So... it's certainly not the base. How about the second offset?


51 02 00 00 -> 00000251 = 0x251 = 512 + 50 + 30 + 1 = 593.



So where does that lead us? Ack! It leads to the middle of another offset! Now, what do we know? There's a pattern of offsetts, but what comes after them? Are they ALL offsets? Lets take a closer look at all the "integers"

00 00 00 00
51 02 00 00
C0 12 00 00
F1 2F 00 00
C0 42 00 00
FA 31 00 00
C0 74 00 00
06 3E 00 00
D0 B2 00 00
E2 3D 00 00
C0 F0 00 00
42 37 00 00
10 28 01 00
C2 3A 00 00
E0 62 01 00
AC 4A 00 00
90 AD 01 00
48 2B 00 00
E0 D8 01 00
A3 3A 00 00

Hmm... Now it doesn't look like everything is an offset, does it? What if I do this?

00 00 00 00  51 02 00 00
C0 12 00 00  F1 2F 00 00
C0 42 00 00  FA 31 00 00
C0 74 00 00  06 3E 00 00
D0 B2 00 00  E2 3D 00 00
C0 F0 00 00  42 37 00 00
10 28 01 00  C2 3A 00 00
E0 62 01 00  AC 4A 00 00
90 AD 01 00  48 2B 00 00
E0 D8 01 00  A3 3A 00 00

We don't know much... but there IS a pattern! The first number seems to be an offset , and the second...could be those flags. Changing the number of columns, and spacing allows us to see that the second "integer" always has two bytes, and then two 0 bytes. This is ALWAYS true. What this could mean is the moves are always 6 bytes, then separated by two null bytes.


I honestly don't know if it helps at all, but that was my thought process from the beginning to now. Learning how to interpret Hex data, is like looking through a random stack of papers, finding patterns, then seeing if these patterns make sense. For example, what I'd do next is simple. If they really are offsets, then I'd test it out more. For example, at the end of this offset table, there are FF bytes, then the beginning of some data. Maybe the first part of this data is offset 0? So is the next part at offset 0x12C0? Trial and eror from there. Eventually, I'd try to figure out exactly how big the first attack is from other clues, and see if it matches anything I know. I hope this helps in your venture =D


And actually, I may research further, and eventually create an attack modifier (This is all from m_attack.bin) It is certainly interesting!


Note: All of this is speculation on my part. I could certainly be wrong. And if I am, I would love for someone to be able to correct me! =D

Edit: As it seems, I'm only partly wrong!
The format is as follows:
0x0000 integer(4): offset (of table/base) (always 0?)
0x0004 integer(4): number of entries in table.
0x0008 (numEntries*8): entries
(numEntries*8) integer(4): padding (0)

Entries: base entryLocation:
0x0000 integer(4): offset to attack data
0x0004 Integer(4): Attack data length

Attack Data is still unknown, however. Hope this is helpful =P

[Kindrindra]

Thanks for all the help!

I think I figured out what the second set of data is- while the first is an offset, the first and second bytes in the second set act as a bookmark of sort, showing where the move data begins, and the third and fourth bytes (aka 00 00) show where the attack data ends!

And, to my surprise, it appears that monster.bat (which I'm hopeful contains the data on the pokemon) is organized in the exact same fashion! I'm not entirely sure what each byte corresponds to, but I think the second last one might be the move's power (when you divide them by 16, you get some numbers suspiciously similar to the "Star" rankings for each move). Monster, on the other hand... I'm going through a list of PMD stats, to see if any of them match up. If I do find a match, well, that's good news!

[Nerketur]

Originally Posted by Kindrindra

Thanks for all the help!

I think I figured out what the second set of data is- while the first is an offset, the first and second bytes in the second set act as a bookmark of sort, showing where the move data begins, and the third and fourth bytes (aka 00 00) show where the attack data ends!

And, to my surprise, it appears that monster.bat (which I'm hopeful contains the data on the pokemon) is organized in the exact same fashion! I'm not entirely sure what each byte corresponds to, but I think the second last one might be the move's power (when you divide them by 16, you get some numbers suspiciously similar to the "Star" rankings for each move). Monster, on the other hand... I'm going through a list of PMD stats, to see if any of them match up. If I do find a match, well, that's good news!

Glad I could help!

I did a bit of research on this, as I was very curious, and I found out a lot of the bin files are simply pack files. So all three of the files in that folder have 593 entries. That's one for every Pokemon. Every one of these entries starts with "PKDPX" and also contains a "SIR0" inside of it. Apparently there's no info on how to unpack PKDPX files, but the SIR0 files seem to be cracked, at least partly. I found info here (Near bottom), and here (Top of page), in case you were interested.

As for me, right now, I'm working on cracking the .SSS, .SSE, and .SSA formats. It looks like they are really all the same format, but the only thing I know from them is initial position data for characters.