View Single Post
Old January 5th, 2012 (12:45 PM). Edited May 3rd, 2014 by Nerketur.
Nerketur's Avatar
Nerketur Nerketur is offline
    Join Date: Nov 2010
    Location: Cyberspace
    Gender: Male
    Nature: Quirky
    Posts: 104
    • Cleaned up a bit
    • New info!

    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" (Constants are NOW thought of as labels!).
    • 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:
    I know all but one word!

    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)
    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:
    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.


    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.)
    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.
    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.
    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.
    .SSA Format:

    current known:
    'Header': Shows where things start.
    1 wrd: number of groups (N)
    1 wrd: length of non-groups/start of groups (Z)
    1 wrd: start of (A) -- Always 4 words?
    1 wrd: Start of pokémon positions (B)
    1 wrd: start of object positions (C)
    1 wrd: start of second non-6 group (D)
    1 wrd: start of third non-6 group (E)
    1 wrd: start of fourth non-6 group (F)
    1 wrd: start of ? (G)
    A wrds from start:
    4 wrd: Something.
    B wrds from start: (Pokmon Positions)
    B6/7wrdGroup -> FFFF*
    C wrds from start: (Objects))
    C8/9wrdGroup -> FFFF*
    D wrds from start:
    8wrdGroup -> FFFF FFFF*
    E wrds from start:
    9wrdGroup -> FFFF*
    F wrds from start:
    G wrds from start:
    Z wrds from start:
    10wrdGroup x N

    group: B6/7wrdGroup
    AAAA: pokemon
    BBBB: Direction
    CCCC: X coordinate -- 8 pixel increments. -- 0 = half of shadow there
    DDDD: Y coordinate -- 0 = Shadow 1 pixel down
    EEEE: ?
    FFFF: ?
    GGGG: FFFF if not used
    group: C8/9wrdGroup
    AAAA: object
    BBBB: ?
    CCCC: ?
    DDDD: ?
    EEEE: X coordinate -- 8 pixel increments. -- 0 = half of shadow there
    FFFF: Y coordinate -- 0 = Shadow 1 pixel down
    GGGG: ?
    HHHH: ?
    IIII: FFFF if not used.

    .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:
    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.
    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? 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 -- (somthing to do with "waittap?". maybe it loads the right value?
    • Testing .SSA files (On hold)
    • -- 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. (almost flawless)
    • Play through certain scenes to understand the script more.
    • Add more file types like .lsd
    • Make code more modular and better
    • ?plugin system?
    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.
    Want my help in PokéScripting? PM me =)
    I use XSE v1.1.1 (HackMew = awesome) and Advance Map 1.92.
    Thanks to Diego and HackMew for their tutorials, helping me learn how to script!

    Hacks I support 100% (MUST SEE!):

    Very well made hacks:

    My work:
    Figuring out scripting in PMD
    Entire script map of LeafGreen
    PMDSE (Pokémon Mystery Dungeon Script Editor)
    Reply With Quote