psy_commando

Member
  • Content count

    350
  • Joined

  • Last visited

Community Reputation

28 Excellent

About psy_commando

  • Rank
    Researcher - ROM
  • Birthday 05/26/88

Recent Profile Visitors

6502 profile views
  1. 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!
  2. 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
  3. 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..
  4. 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!
  5. All the reserve entities are unused afaik. So they can be edited.
  6. 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.
  7. 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.
  8. 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!
  9. 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! ^^
  10. 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.
  11. 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 ^^
  12. 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..
  13. 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.
  14. 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.