Research: Pokemon Mystery Dungeon: Explorers of Time info

[Nerketur]

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]

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]

Originally Posted by droomph

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]

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]

Originally Posted by droomph

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]

aight, got it. And it does seem like the UM/US files are grouped in accordance to maps.

[Anglican]

Is this still being worked on?

[Nerketur]

Originally Posted by Anglican

Is this still being worked on?

Yes, it is. My explanation is on my last post 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]

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]

She's focusing on doing the scripts first, so we're more than glad that you're willing to look into it!

[VERGUNDAI]

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]

Originally Posted by droomph

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

Originally Posted by VERGUNDAI

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:

Spoiler:

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:

Spoiler:

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]

Thanks this is very useful.

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

[Nerketur]

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