psy_commando
-
Posts
425 -
Joined
-
Last visited
-
Days Won
1
Content Type
Profiles
Pokédex
Portal
Technical Documentation
Pages
Tutorials
Forums
Events
Downloads
Gallery
Blogs
Everything posted by psy_commando
-
That's very vague.. But, in terms of the game, modifying dungeons tilesets/layouts, modifying tilesets, modifying animated BGs, fonts. And that's pretty much all I can think of. -
Thanks! ^^ I got character sprite export to work! But I just gotta work out importing images, and editing animations! Soo, it shouldn't be too long until the first release, hopefully! If everything goes well..
-
I haven't mentioned much here in a while but the tool is slowly starting to take shape! I fixed a lot of problems with displaying frames and animations. And I made a small video to show: Its still a work in progress tho!
-
Animashuns Still lots of bugs to fix, and work to do..Cropping ,and well the wrap-around feature of the NDS kinda mess with my cropping algorithm.. Also Qt is basically a minefield of segfaults.. All those pointers just beg for something bad to happen ^^;; Its hell to debug
-
Well I'm trying to get it to be usable soon. But so far I'm having some issues because of the tree view thing.. I might drop that part for something simpler if I can't get things to be tidier and working like I want.. Plus it creates a ton of redundancy.. Also right now it only does import. So keep in mind a big part of the work is left to do You mean the levels graphics and backgrounds? That's coming in another tool! This thing is basically some practice before I get to work on the level editor Here's another peek at the WIP UI. Tho, I feel I could probably make a sort of thumbnail preview instead of the treeview.. I'll have to investigate..
-
So, its been a really long time since I updated this thread! And I've been making some progress on a few things! Namely a sprite editor: Its still really early on tho! But I got some of the stuff behind the scene working finally!
-
ASM Locations in the PMD:Explorers of Sky Games
psy_commando posted a technical document in Mystery Dungeon NDS
Overview This page contains list of the interesting offsets within the game's binaries. The offsets are NDS memory relative, because that's more useful that bin files offsets. Just subtract the binary's load address to get its respective file offset. Functions Functions pointers and some documentation on them. ARM9 Bin (0x2000000) Name Offset NA Offset EU Offset JP Parameters Return value Description MemAlloc 0x2001170 NA NA r0: alloc size r1: unknown r0: Pointer to allocated buffer This function allocates a buffer on the heap of the desired size, and returns a pointer to it. The second parameter's role is unclear.. It might be a flag, since it doesn't seems to change the amount of memory allocated. It can be set to 0. MemFree 0x2001188 NA NA r0: buffer to free none This function free a buffer that was allocated by MemAlloc. ZeroFill 0x2003250 NA NA r0: Buffer to fill r1: Length to fill none This function fills the given buffer with zeros. LoadFileFromRom 0x2008C3C NA NA r0: PtrReturnStruct(Struct is 2 32bits integers, first is ptr of file buffer, second is loaded file length) r1: PtrStrFilePath (Ptr to path to the file to load) r2: Unknown (Set to 0 usually) Unknown This function will load a file from the rom filesystem into a heap allocated buffer. The function allocates the buffer, and fill it with the file data. The address to the buffer containing the file data and its size in bytes are put one after the other into the 8bytes of memory pointed by r0 when running the function! DebugPrint 0x200C240 NA NA Unknown none This function would print to the debug log a printf formated string. But in the retail game it does nothing. Its interesting to note that its still called in the released games and is passed various debug strings and value which can be really useful for research! HandleSIR0Translation 0x201F4B4 NA NA r0: PtrToPtrSIR0BegOfData r1: PtrSrcFileBuffer none This function translates the offsets of a SIR0 file, and change the magic number in the header to SIRO. It places a pointer to the first pointed location in the SIR0 header into the ptr pointed to by r0. Static Variables Addresses of static variables and buffers. Constants Addresses of static constant values. ARM9 Bin (0x2000000) Name Offset NA Offset EU Offset JP Length(bytes) Type Description PackFilesPathsTable 0x20AF6A0 NA NA 24 char*[6] Contains a list of pointers to path strings to all known pack files. The game uses this table to load its resources when launching dungeon play! Should contain pointers to the strings: "MONSTER/monster.bin" "MONSTER/m_attack.bin" "MONSTER/m_ground.bin" "EFFECT/effect.bin" "DUNGEON/dungeon.bin" "BALANCE/m_level.bin" -
All the reserve entities are unused afaik. So they can be edited.
-
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.
-
Level System in the PMD Explorers Games
psy_commando posted a technical document in Mystery Dungeon NDS
Overview This article will try to describe how levels work in the pmd2 games. Engine Modes There are essentially 2 modes that the game can run levels as. In-dungeon, referred to as simply "Dungeon", and out-of-dungeon, referred to as "Ground". Ground mode is the default mode. Dungeon mode is triggered from scripts run by the Ground engine. Dungeon: The dungeon mode is run as soon as a script from the "ground" engine calls the command to run a dungeon. And once a dungeon concludes, execution returns to the line after the command to run the dungeon, and the game falls back into "ground" mode. Scripts aren't executed at all during dungeon mode, since the overlay running scripts is unloaded and replaced with the dungeon engine overlay. Ground: The game runs in this mode as soon as the chunsoft logo pops up on screen. Game scripts are executed only in this mode. The Level Table Located in the ARM9 binary. (arm9.bin) Its a table associating a level ID to level related data. Every "Ground" levels in the game have an entry in this table. Location in the Binaries The table is always inside the arm9 binary, and never in an overlay. Game Game Code Table Offset Nb Entries North American Explorers of Sky C2SE 0xA5488 431 European Explorers of Sky C2SP 0xA5BE0 459 Japanese Explorers of Sky C2SJ 0xA689C 436 Format Each entry is 12 bytes and is laid out this way. Offset Length Type Name Description 0x00 2 int16 mapty Type of the map. A value from 0 to 11 defining how a map is loaded and displayed. 0x02 2 int16 unk2 Unknown value. (0 to 306) 0x04 2 int16 mapid ID number of the map. Most likely used in the bg_list.dat file to look up the level's resources files. 0x06 2 int16 unk4 Unknown value. (-1 to 7) 0x08 4 uint32 ptrstring Pointer to a null terminated string, containing the internal name of the level. Is used as directory name for the script to run, and for debugging. Level Constants and Map Types Depending on the map type, and on the command used to load a level, a different set of constant will be used by the game. TODO -
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.
-
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!
-
Its really great to see the site back up! ^^ There's so much time, work and efforts in those threads, seeing the forum getting erased like that was pretty heartbreaking and discouraging.. Glad that so much could be recovered! ^^
-
Its good to be back
-
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. 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.
-
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 ^^
-
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..
-
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. 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.
-
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.
-
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!
-
Small Update: I found out that the tilesets are compressed. But figuring out how to decompress them is going alright. The hard part is going to be to do the opposite.. Its a bit similar to the nybble patterns used in the PX compression algorithm. The code is kind of a mess, so I'll have to make sense of it now that I was able to transcribe it exactly how it is in the binaries. Still no progress on effect sprites. There's something I'm missing here.. And idk if I mentioned it already, but some effect sprites have literally no image data header. Which just leaves me scratching my head..
-
That definitely looks a lot more similar now! I didn't even realize it was that close.. Yeah, I hadn't encountered type 2 this far. And its possible they're a different format. Or maybe there's something in the meta-frames themselves or some other part of the file, indicating how to parse them? And particle offsets wouldn't make much sense, considering those are the effects that get offset afaik. I think if I do a few modifications to gfx crunch it should be able to rip those. And the tool doesn't recognize a file by extension, but it looks at its structure and can guess if its a sprite or not. But I didn't enable handling type 2 and type 3 sprites because I had not tested those. And I know the the tool tends to crash with non-pokemon sprites. EDIT: I've begun reversing the code parsing the sprites. It looks extremely complicated.. At least, it makes me feel better about how complicated and ugly my code in gfx crunch is..
-
Hey! Did you figure out the weirdness with the pokemon sprite -1 frames? Anyways, I haven't really looked into effects this far. I do know that the effect.bin file is a "pack file" though. Right now there is no obvious way to rip effects. You could use something like tilesGGD on the individual files and try to use part of the file as image data and another as palette and try to see if you get the content to display. That's what I usually do initially with most graphic formats I have to tackle. Sometimes it gives perfect results out of the box with some messing around. And that's funny, gfx crunch seems to just exports the content of the effect.bin pack file like that because it doesn't know the file format, and it apparently labels the result as a monster.md file ^^; gfx crunch is getting a full rewrite soon though.. Its so glitchy and shoddy.. From a quick glance, the format of at least some of the sub-files in the effect.bin pack file seems fairly well structured. And they're SIR0, so its easy to find out what are pointers and what aren't. It should be pretty straightforward to reverse in theory. But yeah, I got a pretty big backlog of stuff to work on, and I'm pretty much the only one actively working on reversing PMD2 formats lately afaik. And I've been pretty much either low on motivation, or dealing with health issues or complicated stuff in the last few days. So, what would really help a lot speed things up would be getting a hand with reversing some of those formats. I've been working on the map tiles lately, and I made some good progress mainly by reading the game code that loads the maps. But its going to take a while to reverse, and I can't really work on too many of these at the same time. And well since nobody has been helping with figuring the remaining commands in the script engine, I've been trying/intending to do it all myself too.. I might take a deeper look at the effect file format this week, but no promises. I can already tell there's a palette and image slices in there. There's a table with pointers pointing to what looks like 4bpp image data chunks, and another one pointing to a palette for one. And a lot of other stuff, probably animation related. It looks a bit similar to the wan format for the sprites, but a lot less complicated.. Thanks for the info! I'm not there yet though. I'm still unsure if dungeon tiles are stored in the same way as regular map tiles. I'll need to be at least able to display the content of the files with probably a test tool before knowing for sure.
-
Released a new update to statsutil. Mainly to fix script compilation issues, and actually display errors when there are some, and not just silently ignore files with errors. I accidentally broke error reporting when I changed the way the parallel script compilation worked. Here's the link : https://github.com/PsyCommando/ppmdu/releases/tag/ppmd_statsutil_0.23.2a EDIT: Also, I forgot to mention, but the tool now generates a compiler_report.txt file which will contain the result of the compilation, with a list of all the errors and warnings about the scripts. Its still pretty basic, glitchy and not very mature yet, but, its leagues better than before
-
@SirLoin4: In this case it was save game editing. But, there are several ways. Like editing the scripts. I made a script edit a while ago and hacking in a little menu to pick both starters via pokemon id. The way the game works prevented it from working properly though. Btu with some asm edits it could probably be made to work. Also, I'm considering getting back into PSMD soon, or at least partially, since citra can emulate it enough now that I can use their debugger. But right now I'm struggling with motivation, especially with the script editor for PMD2, since there has been less interest than expected, and I have to test everything myself. (Also, I have no ideas how to make automated tests for something like that ^^; ) EDIT: Actually evan is right, its a ram edit, but they saved the game afterwards and shared it.
