tool Pokemon Mystery Dungeon 2 - Psy_commando's Tools and research notes

[psy_commando]

I had some time today and ran through a list of all the sir0 files found in the effect.bin, and what WAN-like filetypes they are, assuming they're WAN at all.

http://pastebin.com/UrAGG3TU

I also force-converted the files with the image type of 2 through the gfxcruncher, just curious of the results

https://www.dropbox.com/s/yi904m0da78m4s3/forceChar.zip?dl=0

Even though the palette and image sizes are garbage, the converted product actually survived the process! There's definitely some familiar effects in there that have the same silhouettes as what I manually ripped before... I'm considering comparing them for palette data. Perhaps there's a correlation there...

 

It seems like anything past file 268 is not a wan sprite from looking at that list?

And I'm surprised you got that thing not to crash and burn! The code is mostly a big pile of hacks and patches.. A bit like audioutil ^^;

Its interesting to see some of the effects actually come out properly minus the tiling!

[Tabun_ne]

Yeah, it looks like the last files aren't WAN and happen to be some other format...

I actually ran a script to first rewrite that one byte all the sir0 files since the gfxcruncher didn't work with my current version of c++ (and I'm wary of getting the new Visual studio currently...)

http://pastebin.com/z6rwsX9q

These are my notes for the garbage texture data- I wasn't really aiming for completeness so much as trying to find points of interest to deduce from. There were in fact a number of effects that showed up with the same palette as in the game!

For everything else, though, it looks like the palette data may have some different rules to it when it comes to effects... I need to reread the palette and image notes again for WAN to see what it's supposed to be read as to begin with, though... those parts of the interpretation still confuse me.

In preparation of that, though, I got a look at Embargo. I picked it as the easiest thing to tackle since I recognized the graphics as effect_0156_0x153310, that it was such a small graphical file, and the only thing wrong with it seems to be the wonky palette.

http://pastebin.com/yqpxjM07

Also, the correct palette for Embargo as it's live in-game:

http://i.imgur.com/VtxmdYn.png

Aura Sphere was also notable, because I remember that move's correct palette appearing on a very high palette index when the graphics were loaded into the emulator's tile viewer. I haven't looked at that in depth though...

[Tabun_ne]

http://i.imgur.com/H4koduf.png

There's the meta frame data, palette data, and data for both textures of Embargo there.

Looking at the palette data, I couldn't find any colors that the actual in-game sprite used. However, I remembered something about the way palettes worked with moves in the past: there's always this list of about 8 to 10 palettes that gets loaded in "Main spr EXTPAL", and (nearly) all of the moves in the game use this as a sort of "master" palette. There's still a small amount of exceptions that use their own palette instead of the "master" palette- something I noticed with Aura Sphere, in fact, which would explain why it came out without any color issues!

Following on this hunch, I checked out the sir0 files for Sharpen and Barrage- specifically their Metaframe files. I think I can draw some conclusions:

 

Example Metaframe: FF FF 00 00 ED A1 E9 04 00 7CSections:          00 00 11 22 33 33 44 44 55 67

 

Section 0: This value has been FFFF for every metaframe I could find. I don't know what that means but it seems to definitely NOT be frame index as it was for the character WAN sprites.

Section 1: This section has always been 00. It remains unknown, like the character sprites.

Section 2: This section has been 00, and FB in all the values I've checked so far. The only times it's been FB so far is in certain parts of Embargo's animation. My wild (COMPLETELY UNBACKED) guess is that it determines whether something is drawn behind the target or in front.

Section 3: This section has changed with what appears to be a change in offset. I don't know if, like the character offset, there's some additional flag data embedded in its bytes...

Section 4: Behaves the same as section 3. Probably for the other axis.

Section 5: I am almost sure that this block is related to which image gets drawn. But it's not a simple "Frame 0, Frame 1, Frame 2, etc." relation. There's values that would go way beyond the maximum image count. Maybe it's related to the size of the images?

Section 6: Almost sure that this refers to which palette this sprite is using, when it is loaded into memory. Embargo's correct palette was "Main spr EXTPAL," on palette 7 on runtime. Sharpen's correct palette was 3, which is also its value for this region.

Section 7: This is always C. I don't know why.

With the palette data, I'm thinking that if we can find where that "master palette" data is stored, it can be used to extract all these sprites in the correct color! There's still a lingering uncertainty on how to get dimension data for the images, though... assuming that the effect meta-frames have them like the sprite meta-frames...

When I get the time, I think I'll make changes to the sprites and repack the ROM to do some more experiments...

[psy_commando]

Things tend to get really changed when they're loaded in-game. Like, some 4bpp sprites get converted to 8bpp. If I remember correctly its the case with most sprites used in-dungeon.

And, I'll need to do some code reading to know the details of how all the wan sprites work together for sure.

The best way to test an hypothesis is try to isolate a correlation. Like try changing a few bits of one of the value, expect a result, and write down the outcome. Then try another value. Repeat the exact same steps with a sprite that differs slightly. And after a while, you'll start seeing some things.

On my end I finally got some work done, and I'm on the way to displaying assembled levels from the level data.

I'm just dealing with some issues with resolution and tiling:

[ATTACH=CONFIG]13811[/ATTACH]

EDIT:

While looking at the code for the tilesets, I realized that the format was very close to the data format in memory used in the VRAM for controlling the way images are displayed. And I then thought about the sprites, and it seems like a lot of the parameters found in meta-frames and in the image strips correspond to those :

http://problemkaputt.de/gbatek.htm#lcdobjoamattributes

This should make things easier.

[Prometheus II]

Okay, so this tool seems really useful! I just have one question: is there a way to change abilities? More specifically, can Run Away be outright removed from the game, or - even better - can the data for the Eevee species be changed such that it no longer gets Run Away?

Edit: After becoming possibly a little bit less stupid, I've actually unpacked the ROM and taken a look. I've figured out how to edit Eevee, but I haven't the faintest clue where the data for Run Away's behavior is stored. Statsutil and the overall modding setup don't seem to display .xml files for abilities, unless it's in Scripts. That's very possible, but I have no idea how to discern which script does what. If it helps, I've found the data for Eevee's primary and secondary abilities, but I'm unsure of which is which, and where they reference. I don't see any information on abilities in your notes, although maybe I'm just blind. Any ideas?

Edit again: Okay, I looked into your notes more closely, found the information on abilities in monster.md, and located Run Away. I now know that Run Away is Eevee's primary ability. This is progress. However, I'm still unable to locate the data on how abilities work. Am I just asking questions nobody knows the answers to yet?

Edited October 16, 2016 by Prometheus II

[Tabun_ne]

It's odd... for some reason, the colors in the palette view don't match up with the tile view. For instance in that earlier image with Embargo:

http://i.imgur.com/VtxmdYn.png

The shades of purple found on the embargo diamonds don't match any of the purple in Main Spr Ext PAL. It's messing with my attempts to investigate palette.

Might this be an emulator problem? (I'm using DesMuMe) Have you or anyone else run into this issue?

[evandixon]

Okay, I looked into your notes more closely, found the information on abilities in monster.md, and located Run Away. I now know that Run Away is Eevee's primary ability. This is progress. However, I'm still unable to locate the data on how abilities work. Am I just asking questions nobody knows the answers to yet?

I'd imagine you'd just replace Run Away with something else, like None (or whatever the XML stores the lack of an ability as). If Run Away is the first ability, I'd swap Run Away and Adaptability then replace Run Away with None.

[psy_commando]

Okay, so this tool seems really useful! I just have one question: is there a way to change abilities? More specifically, can Run Away be outright removed from the game, or - even better - can the data for the Eevee species be changed such that it no longer gets Run Away?

Edit: After becoming possibly a little bit less stupid, I've actually unpacked the ROM and taken a look. I've figured out how to edit Eevee, but I haven't the faintest clue where the data for Run Away's behavior is stored. Statsutil and the overall modding setup don't seem to display .xml files for abilities, unless it's in Scripts. That's very possible, but I have no idea how to discern which script does what. If it helps, I've found the data for Eevee's primary and secondary abilities, but I'm unsure of which is which, and where they reference. I don't see any information on abilities in your notes, although maybe I'm just blind. Any ideas?

Edit again: Okay, I looked into your notes more closely, found the information on abilities in monster.md, and located Run Away. I now know that Run Away is Eevee's primary ability. This is progress. However, I'm still unable to locate the data on how abilities work. Am I just asking questions nobody knows the answers to yet?

 

The effect of each abilities is hard-coded. To edit their effect, you'd have to edit the assembler instructions that handles the ability, which is beyond the scope of statsutil.

You can always just swap the ability with something else, like evan said.

It's odd... for some reason, the colors in the palette view don't match up with the tile view. For instance in that earlier image with Embargo:

http://i.imgur.com/VtxmdYn.png

The shades of purple found on the embargo diamonds don't match any of the purple in Main Spr Ext PAL. It's messing with my attempts to investigate palette.

Might this be an emulator problem? (I'm using DesMuMe) Have you or anyone else run into this issue?

 

There can be many reasons why this is happening. Its possible that's not the correct palette slot first of all. And then, the 16 bits palettes from the WAN files are usually stitched and offset after other palettes since there's only a limited amount of palettes available in the VRAM. The individual bytes of the image data are also shifted to match the correct palette.

I can't really give you a better answer on that.

[Prometheus II]

In short, yeah, I'm going into "way too complex" territory. Good to know. Thanks!

[Tabun_ne]

There can be many reasons why this is happening. Its possible that's not the correct palette slot first of all. And then, the 16 bits palettes from the WAN files are usually stitched and offset after other palettes since there's only a limited amount of palettes available in the VRAM. The individual bytes of the image data are also shifted to match the correct palette.

I can't really give you a better answer on that.

Given how both the screenshots are at "Main Spr Ext PAL 7" I can't think of any way the palettes aren't set to the correct slot... I just needed some sanity check to make sure I wasn't making some silly mistake with my emulation. I guess if all else fails I'll skip right to editing the image datas to reference every palette index possible and see what the colors are that way...

[Tabun_ne]

After playing around with the ROM a bunch, it looks like this is how the meta-frames work:

 

Example Metaframe: FF FF 00 00 ED A1 E9 04 00 7CSections:          00 00 11 22 33 44 55 66 77 89

 

Section 0: ALL FFFF

Section 1: ALL 00.

Section 2: 00 or FB. Maybe determines draw-behind?

Section 3: Y Offset

Section 4: Dimensions in Binary Flags: 0123 4567

01: 00 in Sharpen and Barrage, 10 in Embargo

2: Unknown (ALL 1)

3: Mosaic Mode (ALL 0)

45: Unknown (ALL 00)

67: Upper Bits for Y offset

Section 5: X OFfset?

Section 6: Dimensions in Binary Flags: 0123 4567

01: Size; 00=8x8, 01=16x16, 10=32x32, 11=64x64

2: Flip Vertical

3: Flip Horizontal

4: Is Last Meta Frame in Group (1 in Sharpen and Barrage, SOMETIMES in Embargo)

56: Unknown (ALL 10)

7: Upper Bits for X Offset (SOMETIMES 1 in Embargo)

Section 7: Image Offset by blocks. 1 LSB = 2 8x8 textures. Examples:

+1 for 8x8 Sharpen (will skip 1 block; the game appears to add 1 block space to 1-block textures)

+1 for 8x16 Embargo (8x16 = 2 blocks)

+2 for 16x16 Barrage (16x16 = 4 blocks)

+2 for 16x16 Sharpen (16x16 = 4 blocks)

+8 for 32x32 Sharpen (32x32 = 16 blocks)

Section 8: Palette Index. Values of 0 to C all appear to exist outside the file. They reference a palette that, on runtime, remains static. Values at D and E seem to use custom palettes that may or may not exist in the current file.

Section 9: ALL C

Section 4 and Section 6 are not completely confirmed, but the flags for size, flip, and horizontal/vertical dimensions are the same. It's pretty much following the same pattern as WAN sprites, except it's LITTLE-endian. Even though there's no variable for image index, it looks like ti can still be figured out be reading Section 7, which deals with memory offsets.

Also, it appears that colors in the Palette viewer (And presumably in the memory itself) need to be multiplied by 32, then divided by 31 in order to achieve the correct colors displayed in-game.

There's just one issue remaining... and that is regarding the palette data of these effects. None of the palette data that actually shows up as colors used in the game appears to be stored in these files. There are some exceptions, such as with Aura Sphere- but it appears that the file has only one of several palettes needed to display that move properly. And even then, the one palette that appears to be stored in the file is not 1:1 with the colors used in the game, or even the palette data that shows up on runtime. So now we have palette data in the file, palette data in memory, and palette data in the actual game/tile map, all of which are different...

So the questions left unanswered are:

-Where are the correct colors for these effect sprites, for the files that do not have them?

-What operation needs to be done in order to transform existing colors in the files to the colors actually used on runtime?

EDIT: Ok so I edited effect_0178_0x194630.sir0 (Dragon Pulse) to use the following info as its palette data:

 

00 00 00 80 FF 00 00 80 FF 20 00 80 FF 40 00 80 FF 60 00 80 FF 80 00 80 FF A0 00 80 FF C0 00 80 FF E0 00 80 FF FF 00 80 E0 FF 00 80 C0 FF 00 80 A0 FF 00 80 80 FF 00 80 60 FF 00 80 40 FF 00 80 20 FF 00 80 00 FF 00 80 00 FF 20 80 00 FF 40 80 00 FF 60 80 00 FF 80 80 00 FF A0 80 00 FF C0 80 00 FF E0 80 00 FF FF 80 00 E0 FF 80 00 C0 FF 80 00 A0 FF 80 00 80 FF 80 00 60 FF 80 00 40 FF 80 00 20 FF 80 00 00 FF 80 20 00 FF 80 40 00 FF 80 60 00 FF 80 80 00 FF 80 A0 00 FF 80 C0 00 FF 80 E0 00 FF 80 FF 00 FF 80 FF 00 E0 80 FF 00 C0 80 FF 00 A0 80 FF 00 80 80 FF 00 60 80 FF 00 40 80

 

It's basically a cycle of all the rainbow colors. The result was pretty interesting:

http://i.imgur.com/NqsbvOr.png

The rainbow-cycle apparently goes out to palettes 13, 14, and 15. And it also appears to prove that, with Dragon Pulse's live sprite changing, that all of the palette info is indeed coming from the effect file itself. Somehow. At least for Dragon Pulse and other files that use palettes 13-15.

EDIT 2: To be comprehensive, I also blanked out the entire palette for Sharpen and observed the results. Nothing happened, so it looks like every move using palettes 12 and below are actually getting them from somewhere else.

Edited October 29, 2016 by Tabun_ne

[psy_commando]

After playing around with the ROM a bunch, it looks like this is how the meta-frames work:

EDIT: Ok so I edited effect_0178_0x194630.sir0 (Dragon Pulse) to use the following info as its palette data:

 

00 00 00 80 FF 00 00 80 FF 20 00 80 FF 40 00 80 FF 60 00 80 FF 80 00 80 FF A0 00 80 FF C0 00 80 FF E0 00 80 FF FF 00 80 E0 FF 00 80 C0 FF 00 80 A0 FF 00 80 80 FF 00 80 60 FF 00 80 40 FF 00 80 20 FF 00 80 00 FF 00 80 00 FF 20 80 00 FF 40 80 00 FF 60 80 00 FF 80 80 00 FF A0 80 00 FF C0 80 00 FF E0 80 00 FF FF 80 00 E0 FF 80 00 C0 FF 80 00 A0 FF 80 00 80 FF 80 00 60 FF 80 00 40 FF 80 00 20 FF 80 00 00 FF 80 20 00 FF 80 40 00 FF 80 60 00 FF 80 80 00 FF 80 A0 00 FF 80 C0 00 FF 80 E0 00 FF 80 FF 00 FF 80 FF 00 E0 80 FF 00 C0 80 FF 00 A0 80 FF 00 80 80 FF 00 60 80 FF 00 40 80

 

It's basically a cycle of all the rainbow colors. The result was pretty interesting:

http://i.imgur.com/NqsbvOr.png

The rainbow-cycle apparently goes out to palettes 13, 14, and 15. And it also appears to prove that, with Dragon Pulse's live sprite changing, that all of the palette info is indeed coming from the effect file itself. Somehow. At least for Dragon Pulse and other files that use palettes 13-15.

EDIT 2: To be comprehensive, I also blanked out the entire palette for Sharpen and observed the results. Nothing happened, so it looks like every move using palettes 12 and below are actually getting them from somewhere else.

 

Hmm, that's really interesting!

So I guess, sprite files might be able to use existing palettes.. Maybe sprites within a pack file are actually all compiled to work together? That would mean -1 frames are a bit more logical then..

I've noticed that some of the code for the tilesets seems to be used for other purposes. And I suspect it might work for sprites too.. I'll have to do some more debugging first though.

EDIT:

Oh and speaking of tilesets! I've tried assembling some using the mapping data within the BPC files and I'm definitely going somewhere

Here's the lower layer of treasure town:

[ATTACH=CONFIG]13830[/ATTACH]

I'm assuming part of the blank parts are for animated stuff like water. And I still don't quite have the right dimensions..

And here's the temple thing with the rainbow stoneship in the intro screen:

[ATTACH=CONFIG]13831[/ATTACH]

It really close, but not quite there yet..

[Mariohuge]

If I may ask, how far have we gotten to editing which scripts are called when? Like triggering a boss battle or a cutscene? I'm really hoping to make my own set of special episodes, so figuring out how to trigger a dungeon entrance or a boss battle is essential for what I'm planning.

Also, are you planning on making a GUI for editing scripts directly, or will it stay as requiring notepad? It's a bit tough to tell how large a textbox is going to be, or which music will play during a cutscene, so an interface would help out very much.

I've said it a lot already, but I'm very impressed with how far you've managed to take PMD modding! I really appreciate all your hard work!

[psy_commando]

If I may ask, how far have we gotten to editing which scripts are called when? Like triggering a boss battle or a cutscene? I'm really hoping to make my own set of special episodes, so figuring out how to trigger a dungeon entrance or a boss battle is essential for what I'm planning.

Also, are you planning on making a GUI for editing scripts directly, or will it stay as requiring notepad? It's a bit tough to tell how large a textbox is going to be, or which music will play during a cutscene, so an interface would help out very much.

I've said it a lot already, but I'm very impressed with how far you've managed to take PMD modding! I really appreciate all your hard work!

 

Those are already fairly well understood. The master script aka unionall.ssb/common.xml is what calls the various levels/scenes among other things.

If you look at "CommonRoutine #111 - EVENT_M01_01_02" that's what runs everything when starting a new game!(minus the personality test as its hard-coded) You can see it executes several scripts one after the other using "supervision_ExecuteActingSub". Those all load a level and run its attached script in the matching xml file/directory.

And other events are executed in similarly named common routines "EVENT_M01_01_02", "EVENT_M01_03", "EVENT_M01_04", "EVENT_M01_05", "EVENT_M01_06", "EVENT_M01_07_08", "EVENT_M02_01_02", etc..

(Those are the debug names from the game data)

What calls those events is a monstrous set of common routines with names starting by "EVENT_DIVIDE". Those are huge conditional blocks that use "JumpCommon" commands to run the appropriate event's routine based on the state of the game variables, aka "flag".

Cutscenes are all within the script themselves. Boss battles are essentially fixed dungeon rooms and are loaded using the dungeon loading command like any other dungeon.

In the current state of the script editor you can already do code reading and fairly easily determine what does what. Not all commands and parameters have been analyzed so far, but its a pretty big job, and I was starting to lose interest by having to document all those myself and just moved on to maps for now.

I also need to make a new release for the script decompiler soon to fix escaped characters not working in some cases, and to add support for "performers", thanks to some of Aissurteivos's findings!

And, well, textbox are always fixed size, and the music is numbered after the content of the BGM folder. A lot of the documented values are stored in the program's XML files. I'm also planning on giving things more meaningful names once I can say with certainty what they actually do.

I'm not planning on making a tool to edit scripts only by themselves. They're too integrated with other things to do something handling scripts only. Like script data files actually also contains entities, events, and props placement data for a level..

And well, as it is, adding levels and etc will require to install an ASM mod on the game I've made so that the game loads the level list from a file instead of it being hard-coded. So considering all this, I thought it was better to just wait and integrate the script editing to a larger more feature full utility.

With that said, I'm planning on integrating scripts to a full-fledged level editor. With a GUI made using Qt. So for instance, most manual editing of the xml would be eliminated and most of it automated / simplified by the GUI.

I've been aiming for something a bit close to RPG Maker 2003. Since the scripting system is very similar in several ways. It might not be as advanced as RPG Maker though, but it will be a lot easier to edit levels than editing lines of text. I might need some backup on this one since it a big project though.

Thanks for the encouragements btw! Its really appreciated ^^

Edited November 12, 2016 by psy_commando

[Mariohuge]

Ah, I see! Thanks for directing me to the COMMON.xml! And this level editor sounds very intriguing. I might not be that good at developing tools like that just yet, but if you ever need anyone to test it out I'd love to do so!

[Tabun_ne]

I'm taking a break from VFX ripping... I got pretty far, but the last step demands more free time than I have at the moment...

I'm more curious about dungeon data now. Has there been any headway made in the past regarding the stats for the dungeons? According to the notes I was able to find on the subject, that data seems to be found in /BALANCE/. But which files would they be?

[evandixon]

I'm taking a break from VFX ripping... I got pretty far, but the last step demands more free time than I have at the moment...

I'm more curious about dungeon data now. Has there been any headway made in the past regarding the stats for the dungeons? According to the notes I was able to find on the subject, that data seems to be found in /BALANCE/. But which files would they be?

The dungeon stats are stored in mappa_s.bin. The gist of what we know can be found at mdrngzer's docs. Psy_commando has notes somewhere with a little more structural information, and if you want to read some VB.Net source code, I have a class that can parse mappa_s.bin files here.

[psy_commando]

Ah, I see! Thanks for directing me to the COMMON.xml! And this level editor sounds very intriguing. I might not be that good at developing tools like that just yet, but if you ever need anyone to test it out I'd love to do so!

 

Alright

Also, I have been writing a work in progress guide to how the script engine works :

https://dl.dropboxusercontent.com/u/13343993/my_pmd_research_files/ScriptEngine/AboutTheScriptEngine.txt

Mainly to help people use the script decompiler/compiler.

I'm taking a break from VFX ripping... I got pretty far, but the last step demands more free time than I have at the moment...

I'm more curious about dungeon data now. Has there been any headway made in the past regarding the stats for the dungeons? According to the notes I was able to find on the subject, that data seems to be found in /BALANCE/. But which files would they be?

 

A good part of it is inside the file evan mentioned, but the actual floor layouts, and several item lists and most likely a lot more are stored elsewhere. We know some iterm lists are hardcoded in the executable from reading the thread on gamefaqs made by ogregunner and others.

[psy_commando]

Its good to be  back

[Andibad]

57 minutes ago, psy_commando said:

Its good to be  back

yeah, but is little bit slow to access some pages.

[psy_commando]

So, since its been a while since I made an update, I'll mention that I've been mostly disassembling code for reading the maps, and trying to understand the logic behind it. I also made a lot of refactoring to make the config file loading more flexible in my tools and rethink several parts of the system I designed for handling maps and scripts.

I've also laid down the basics for a new tool called "MapNybbler" (Yet another bite pun ) which will ideally be essentially the back-end of the map editor I have planned. That tool will focus on map tilesets, maps themselves, entities, objects, applying asm mods to extend the game's level engine, and the scripts. (Statsutil will still support scripts, but MapNybbler will take over as preferred script tool, considering I can do a lot more in terms of simplifying everything if I can tie a map's resources to a script. )

So far, I'm planning 2 asm mods to be released with the tool. One of the entity table, and one for the level table. Both will allow adding new levels/entities to the game, and allow more control than with the hard-coded lists built-in the game right now.

 

Here's a quick overview so far of what I know about maps summed up :

- My WIP notes on the map tilesets and map data formats : https://dl.dropboxusercontent.com/u/13343993/my_pmd_research_files/FileFormats/BMA-BPL-BPC-BPA.txt

- Each level has an entry in a table inside the arm 9 binary. The entry contains a few values, but the most interesting ones are the type of the map, and the name of it (pointer to string).

- When the name of the current map is looked up in the table when loading a map, it runs either the "enter" script or an "acting" script within the folder with the same name the map has in the table.Then the script will load a "background" which is essentially a tileset within the "MAP_BG" directory. But in order to do this, the game will look at the "bg_list.dat" file and look at the filenames for the entry matching the current map id. There are usually 3 strings, one for the filename of the BPC, BPL, and BMA corresponding to this map. There can be more strings for maps that have BPAs too!

- The command used in the script to load a map affects the way it will be laid out and displayed. There are 3 sets of constants for each map types, each set being tied to a specific map loading function. So, some level expects BPAs, some don't. Some have different resolutions for the BPC layers too.

- BPC files contains anywhere between one and 2 layers. Each layer has a 4bpp tileset, and a tilemap one after the other, and compressed.

- BMA files contains lots of details on the format of the layers and how to assemble and display them. But I'm not yet completely sure what everything does. And I'm still researching.

- BPA files contains raw 4bpp images, and possibly some map tiling data. Those seems to be stitched to either BPC layer, and often seems to contain animated parts of the tileset. Still researching!

- BPL files contains palette data for the other matching BMA, BPC, BPA files. it normally contains 15 palettes. But a boolean in the header can allow this to be extended to several more palettes, possibly meant for animated bg.

More details to come! I just need to figure out how maps are stitched together and things should be much easier from that point!

[TyVogue64]

So, now that we can edit graphics somewhat and edit stats and learnsets, does anyone know if the number of species of Pokémon is hardcoded, and if it is, how hard would it be to rewrite the ASM to allow for more? The 309 Pokémon added since this game came out to be exact! 

 

OK, so there probably wouldn't be much point in adding that many until we could add more dungeons for them to populate. So is the amount of dungeons hardcoded too? Does every dungeon have a unique entry in the actual code, or is all of its info just stored in a file?

 

And then the amount of sprites that would need to be drawn. Each one already in the game has around 40 or so, so at least 12,360!

 

And then there's the problem of the Fairy type, which I'm sure would be almost impossible, this, for reference, was only possible because they replaced the ??? type, which IIRC, doesn't exist in PMD2. So, many Pokémon would be left without one of their types, or would have to be retyped completely.

 

And I just explained why it would be completely impractical. 

 

Raising the cap would probably be best for just adding a few favourites without removing any of the already existing ones. Replacing Primal Dialga would deprive the game of its fairly challenging "final" boss and I imagine replacing purple Kecleon would cause some issues.

[psy_commando]

Well, there's no "species". Each regular pokemon's form has 2 entities, one for each gender, and there are extra entities for some unique NPCs. There's 1,200 slots for entities in total. Its most likely possible to make an asm mod to increase that number. But I have no ideas how difficult or time consuming it would be since I haven't looked into that yet.

Dungeon data isn't hardcoded. We haven't tried adding new entries to the dungeon data file though. So we don't know if there is any modifications needed there. And we're still not sure how and where the dungeon tilesets are stored.

Adding a new type is most likely possible through modifications. And I mean without that hack those guys you linked did.

 

[TyVogue64]

23 hours ago, psy_commando said:

Well, there's no "species". Each regular pokemon's form has 2 entities, one for each gender, and there are extra entities for some unique NPCs. There's 1,200 slots for entities in total. Its most likely possible to make an asm mod to increase that number. But I have no ideas how difficult or time consuming it would be since I haven't looked into that yet.

Dungeon data isn't hardcoded. We haven't tried adding new entries to the dungeon data file though. So we don't know if there is any modifications needed there. And we're still not sure how and where the dungeon tilesets are stored.

Adding a new type is most likely possible through modifications. And I mean without that hack those guys you linked did.

 

 

Hmm... that's interesting. So then, Castform would have 8 entities, right?

I was looking through the XMLs your Statsutil spat out, and what you've said seems to be true. Dialga and Kecleon have two entries, for obvious reasons. But what's odd is that I checked Groudon, a neuter Pokémon, and it also has two "genders", 3 and 0. I also checked Tyrogue, an all male Pokémon, and they have 1 and 0. So 1 is male, 2 is female, 3 is neuter and the secondary "gender" is set to 0 if it's not used. But where is the fake Groudon from early on in the game? Is it actually just a real Groudon at a lower level, but the event that allows it to join you only triggers when you defeat him again in the post game? Which would make sense, legends aren't recruited normally, and have a recruit rate of -100, which will never reach 1 even with all of the recruitment items.

But I checked Elektrike, who you fight several of during the main story of Sky, and they have two "genders" and a recruitment rate of 64. So, I'm guessing there's just a "boss flag" and one for dungeons like Beach Cave that prevent you from recruiting them.

That info about adding a new type sounds interesting, even though it probably involves some ASM trickery, I'm surprised it's easier that adding more entities or dungeons. Would we able to retype Ralts and Jigglypuff and the move Charm to be Fairy, and make it appear in their summaries? That'd be pretty impressive.

[psy_commando]

Yep.

And all genderless or male or female only species have a counterpart entity as well. Its a dummy though. Its only there to keep both gender entry tables aligned within the data files.

Bosses works differently. The NPC that appears on the map is a special entity that's only meant for the cutscene. We still don't know yet for sure how bosses works. But we have some ideas. I suspect fixed.bin to have part of the answer.

Well it depends on how typing effectiveness is implemented. But if its just a table, it would be trivial to hook everything accessing it and inject a larger table  somewhere, or just load it dynamically. That's what I did with the levels and NPCs for instance. Its not really trickery, its just rewriting part of the game code to do something slightly different.