PDA

View Full Version : Research: Pokemon Mystery Dungeon: Explorers of Time info


Nerketur
January 5th, 2012, 12:45 PM
Updates:

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!

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.

.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:
8wrdGroup*
G wrds from start:
? FFFF FFFF FFFF
Z wrds from start:
10wrdGroup x N

--------------
group: B6/7wrdGroup
AAAABBBBCCCCDDDDEEEEFFFFGGGG
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
AAAABBBBCCCCDDDDEEEEFFFFGGGGHHHHIIII
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.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 -- (somthing to do with "waittap?". maybe it loads the right value?
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. (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 (http://www.pokecommunity.com/showthread.php?t=282629).

Nerketur
January 31st, 2012, 07:49 PM
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:


Real-time editing: Hex and assembly changes as you work.
Tree structure for scripts
XSE-like structure for editing
Planned support for all current and future versions of PMD
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. http://dl.dropbox.com/u/15751634/PMD/PMDSE/Screenshot.png

Team Fail
January 31st, 2012, 08:42 PM
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
February 1st, 2012, 06:55 AM
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
February 1st, 2012, 03:17 PM
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
February 1st, 2012, 03:24 PM
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?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:


Real-time editing: Hex and assembly changes as you work.
Tree structure for scripts
XSE-like structure for editing
Planned support for all current and future versions of PMD
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. http://dl.dropbox.com/u/15751634/PMD/PMDSE/Screenshot.pngI 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
February 1st, 2012, 08:26 PM
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
February 1st, 2012, 09:19 PM
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
February 1st, 2012, 09:48 PM
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
February 3rd, 2012, 05:02 PM
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
February 4th, 2012, 08:11 AM
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
April 3rd, 2012, 11:20 AM
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
April 14th, 2012, 07:37 PM
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
April 17th, 2012, 08:01 AM
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
April 17th, 2012, 11:57 AM
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
May 28th, 2012, 09:56 PM
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 3Example 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
May 30th, 2012, 08:17 AM
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
May 30th, 2012, 10:19 AM
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
May 31st, 2012, 06:28 PM
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
June 7th, 2012, 10:11 AM
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
June 16th, 2012, 07:49 PM
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
June 18th, 2012, 08:01 AM
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
June 18th, 2012, 08:51 AM
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 00To 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 00Hmm... 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 00We 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
June 19th, 2012, 07:28 AM
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
June 19th, 2012, 07:48 AM
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 (http://gbatemp.net/topic/303529-tinke-072/page__st__60) (Near bottom), and here (http://gbatemp.net/topic/303529-tinke-072/page__st__165) (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.

Nerketur
June 29th, 2012, 09:57 PM
Lots of work done. Learned a few more commands, and I'm starting to understand the entire structure of script files. It's pretty interesting. I'll have to create documentation of what I know, but that will come at a later date.

Stuff to do:


Figure out more about .SSA, .SSE, and .SSS files
understand structure of a few more Sky commands
and a lot more.

droomph
July 9th, 2012, 12:07 PM
Also, I have to ask...

Why does the "story" scripts seem to react to change, while the "overworld" (the ones you have to voluntarily activate) doesn't seem to change when you change something?

Nerketur
July 9th, 2012, 01:37 PM
Also, I have to ask...

Why does the "story" scripts seem to react to change, while the "overworld" (the ones you have to voluntarily activate) doesn't seem to change when you change something?
If you mean the UMXX anf/or USXX files, I haven't tested them... but I do know that there are a lot of repeats in those files. So it could be running from one of the 'repeats' that you didn't happen to change.

I don't fully understand the talking to people just yet, so I'm not sure. If you meant the enter events, however, then I haven't a clue why.

droomph
July 9th, 2012, 01:54 PM
I've checked. And nope, they're all .ssb files. No matter what, they won't change - and surprisingly enough, only one copy of the file exists so I don't know what I'm doing wrong.

For example, if I change Ledyba's script, it does nothing at all to affect the game, but when I changed the Beach Cave events, it changes.

Nerketur
July 9th, 2012, 03:30 PM
I've checked. And nope, they're all .ssb files. No matter what, they won't change - and surprisingly enough, only one copy of the file exists so I don't know what I'm doing wrong.

For example, if I change Ledyba's script, it does nothing at all to affect the game, but when I changed the Beach Cave events, it changes.
Exactly as I predicted, then =) And, exactly what I said in the previous post.

"If you mean the UMXX anf/or USXX files, I haven't tested them... but I do know that there are a lot of repeats in those files. So it could be running from one of the 'repeats' that you didn't happen to change."

droomph
July 10th, 2012, 02:57 PM
aight, got it. And it does seem like the UM/US files are grouped in accordance to maps.

UnderMybrella
October 1st, 2012, 09:42 PM
Is this still being worked on?

Nerketur
October 5th, 2012, 07:39 PM
Is this still being worked on?
Yes, it is. My explanation is on my last post (http://www.pokecommunity.com/showpost.php?p=7352195&postcount=35) in the tools thread, but a summarized version Ill put here. I haven't been able to work on this at all lately, because of school and all that. I'm a master student of Computer Science now, and so my time is severely limited. But, I WILL be continuing to work on this, especially over this weekend, because I have fall break =D

VERGUNDAI
October 6th, 2012, 04:50 AM
Nice tool, im a big fan of PMD too!

- Are you thinking about a sprite editor?

If not I'm thinking about looking into it.

droomph
October 6th, 2012, 10:10 AM
She's focusing on doing the scripts first, so we're more than glad that you're willing to look into it!

VERGUNDAI
October 6th, 2012, 04:30 PM
My progress...,
- Just starting a program on editing the OW sprites
and it's not editable yet because some sprites don't have correct pallete offsets...

If anyone find sprite pallette offsets pm me /but I might find it soon..

Nerketur
October 7th, 2012, 09:19 PM
She's focusing on doing the scripts first, so we're more than glad that you're willing to look into it!

She? I'm no she. =P

My progress...,
- Just starting a program on editing the OW sprites
and it's not editable yet because some sprites don't have correct pallete offsets...

If anyone find sprite pallette offsets pm me /but I might find it soon..
I'm not sure about palettes, but I do know a bit about how the SIR0 files (in the BIN files) are organized.

All of the images of each Pokemon are in their own SIR0 file, and there are 593 of those. (The bin file is just a collection of those SIR0 files.

Format of the images are in 8x8 blocks, 4 bits per pixel.
How the image is laid out is shown right after the pixels. I do not know where the palette data is stored, though.

Outline:
SIR0:
Some type of data
picture
data for above picture
(repeat above ad nauseum)
some pointer data

Picture data:
12 bytes per part, followed by 12 0x0 bytes to signify the end.
XXXX ???? YYYY ???? ZZZZ ????

first 2 are a word showing pixel data (-0x29?)
XXXX: if XXXX = 0, then we put blanks here
otherwise, we put data
YYYY = Length of the data to put. (in bytes)
Note that because the data is in 8x8 blocks of pixels, and each pixel is 4 bits long (16 colors), this will ALWAYS be a multiple of 0x20 (8*4)
ZZZZ: All I know about this is that it can be 0, or 1. I assume it refers to Z indexing, but I'm likely wrong.

Note on how data is arranged:
ALL data is arranged on 32x32 blocks. We only put the data on the full blocks.
So, lets say an image looked like:
1 2
3456
7 8
(Here, the numbers represent 8x8 sections)

The data would be laid out as:
12345678
(1 addr) 0x0000 0x0020 0x0000 0x0000 0x0000
0x0000 0x0000 0x0020 0x0000 0x0000 0x0000
(2 addr) 0x0000 0x0020 0x0000 0x0000 0x0000
0x0000 0x0000 0x0020 0x0000 0x0000 0x0000
(3 addr) 0x0000 0x00A0 0x0000 0x0000 0x0000
0x0000 0x0000 0x0020 0x0000 0x0000 0x0000
(8 addr) 0x0000 0x0020 0x0000 0x0000 0x0000
0x0000 0x0000 0x00A0 0x0000 0x0000 0x0000
0x0000 0x0000 0x0000 0x0000 0x0000 0x0000


More notes on how Data is arranged:
Everything is based on a 32x32 block, as follows:
0123
4567
89AB
CDEF

If there are more, the second block is always to the right of the first.
For example, if the hexadecimal numbers represent 32x32 blocks, they are laid out in this order.
0149
235A
678B
CDEF

The smallest image is technically a 32x32 block, with "blanks" appended.
So, as a more concrete example, this image (in 8x8 blocks)
1 2
345
6 7

Really looks like this to the game ('.' represents a blank 8x8 tile):
1.2.
345.
6.7.
....


I also looked a little into the format, and noticed the near end of file's offsets, -(0xF7), give you the correct offsets to the pictures. But that's all I know, and that's also as far as I'll look into it for now =) If someone wants to figure it out from there, be my guest. =D

Edit: I may as well mention, the sprites for the Pokémon are in m_ground.bin, in the MONSTER folder, if you unpacked the ROM. And I only know the offsets are true for the Bulbasaur file. It may or may not be the same for the others.

VERGUNDAI
October 7th, 2012, 09:43 PM
Thanks this is very useful.

- when i fix the bugs on my tool i will release it!

Nerketur
January 21st, 2013, 03:33 PM
Wanted to give a small little update! I'm still here, and still working on this project, but I've come to sort of a standstill. I think I officially know all that can be known without understanding the inner workings of the game. How it changes scripts, what it puts on the stack, that kind of stuff. What I really need is someone who is really good at looking at the internals of a game and understanding how it works. I know a little of ASM, but I have no real debugger of sorts. DS games are harder to debug, after all. I might use other emulators than No$GBA, but it's fastest on my compy, and debugging would go real slowly on other emulators. We'll see.

Another new piece of news, is I was able to contact Sebbe! I thought I emailed him yesterday, but apparently I didn't and I'll have to remake it. Oh well. I'll do that today, then. Either way, that means I may get much more info on Blue and Red Rescue Team! I'm getting excited already =P

All that said, updates will be much less frequent until summer. I'll still work on it a little each day if I can, but don't expect a beta anytime soon. I have ideas on how I can continue, and it all starts with understanding actions. =) So I'll work on understanding those next. So, until next time, I'm out! =D