Jump to content

psy_commando

Innovator
  • Posts

    425
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by psy_commando

  1. Its not yet possible to "add" pokemon. You can replace some of them though. But you need to know how. I'd wait for someone to make a frontend for my tools before trying to do it, because its a bit more complicated than the portraits.. I know someone that replaced a pokemon with minccino sprites, and portraits made by someone. And also, there are still things we don't really understand about the game yet.
  2. I managed to change the starter correctly this time ! [ATTACH=CONFIG]12797[/ATTACH] [ATTACH=CONFIG]12798[/ATTACH] [ATTACH=CONFIG]12799[/ATTACH] [ATTACH=CONFIG]12800[/ATTACH] The move set is all wrong though.. And I'm not sure where the game gets the movesets it give each pokes.. [ATTACH=CONFIG]12802[/ATTACH] And because of the really stupid way they're handling cutscenes, we may need a new cutscene actor for each new starters. Or maybe we can just re-use the same actor for any new starters.. We'll see.. EDIT: Spotted some more weirdness: [ATTACH=CONFIG]12803[/ATTACH] The ability was also set to something else than it should be. It seems like the level-up move list is working as expected though.
  3. I was able to find the correct fork of ctrtool to decompress the exefs's code.bin in PSMD ! And I ran strings on it. And its like christmas morning! https://dl.dropboxusercontent.com/u/13343993/my_pmd_research_files/PSMD/PSMD_codebin_strings.txt So much info in there ! Its like they left debug symbols ! I can see they're using the boost c++ libs, and also that jenkins is a very sloppy employe I wonder how I can get radare2 to properly use those.. Any arm binary experts around here ? There's also a lot of lua code inside strings literals Possibly with a mod. But for save game stuff, you'll have to ask evandixon. EDIT: Turns out, jenkins might just be an automated build server software : https://wiki.jenkins-ci.org/display/JENKINS/Meet+Jenkins
  4. Well, its not ready yet. That image looks good, but, the game is stuck in an infinite loop past that point.. The personality test keeps popping back, which is the game's way of crashing. It did something similar in GTI. I just have to find out what's going on.. It might have something to do with reloading the models, or maybe something else entirely.. Good to know ! And sorry for not understanding what you meant earlier ^^;
  5. Well, it seems only a part of the decompiled scripts differs. And it would kinda defeat the purpose of using IDs if you'd need to change them with a different language. That's why I changed my mind on them being hashes a while ago. After looking at the changed scripts, its just some things like using a localized sprite instead of another, and function name changes. All the strings IDs stayed the same. Also, I'm making some progress messing with the game's internals. I got this messing with actors data : [ATTACH=CONFIG]12796[/ATTACH] ( I'm so predictable ) It seems changing starters isn't as easy as it was in GTI though. But I got a good lead. Its just really annoying to have to rebuild the entire rom and copy it each times you change 3 tiny files.. Hopefully hans gets updated one day to work like game patches.. @Silverhawke: Those animation names seems to match those in the scripts. And those special utf characters are interesting. In previous games, the codes for doing that were between square brackets. Its strange to see they've changed their approach And yet they're still using SIR0, ever since Red Rescue Team..
  6. So, I was able to rip my own cartridge of the game today, and I ran winmerge with the japanese rom and mine on the content, and then on the script. Here are the reports : Full content compare: https://dl.dropboxusercontent.com/u/13343993/my_pmd_research_files/PSMD/PSMD_us_ja_romfs_compare_report.html Decompiled scripts compare: https://dl.dropboxusercontent.com/u/13343993/my_pmd_research_files/PSMD/PSMD_us_ja_script_compare_report.html Its interesting that more than expected changed! Especially the scripts. I'm going to work on investigating the scripts and actor and placement data for now I think. Which SIR0 reader ? There are 3 of them I think ^^; Also, I'll only add something to the first post if the author ask me to. And I don't think anyone seems to really know what BGRS files are for. At least it seems like that. How can you tell they're for animations ? And that seems to make sense. I guess that's possible its because the files were in alphabetical order I'm not really sure what you're trying to say here And the image is too small to see anything. Yeah, the padding bytes change from game to game. But I'm not sure what that has to do with this?
  7. New release of audioutil ! I implemented the rendering of audio envelope into the samples and, it made quite a difference. (MIDI rendered without additional processing in Foobar2000 with the MIDI plugin) https://dl.dropboxusercontent.com/u/13343993/my_pmd_research_files/converted_with_audioutil/Dec3/84_B_EVENT_SEPARAT.mp3 It will never be perfect that way though. I'll be making an audio player to do the job properly. Also, the issue with some of the sample being completely off-pitch is still not solved. I've been asking around to find a solution though. Here's the release. This one is pretty rough around the edges, but its been a long while since the last release, and well the last one was problematic to say the least.. https://github.com/PsyCommando/ppmdu/releases/tag/ppmd_audioutil_0.20 EDIT: Feedback very much welcome by the way! I can't do much to improve the tool without that!
  8. The encoded pointer list must end on a 0. It will keep going until it hits one. So, yep, that's not padding. All those 0xC are actually offsets to pointers within the SIR0 container. http://projectpokemon.org/wiki/Pmd2_SIR0#Pointer_Offsets_List
  9. The WAN file format is used in Pokémon Mystery Dungeon: Explorers of Time/Darkness/Sky to store animated character sprites along with map props, and even some UI elements. This format is always wrapped by a SIR0 container, and it doesn't possess its own magic number. However, it does have its own header and structure. Its one of the most complex formats used in the game. It can have a different file extension, depending on the type of sprite it contains. So far, WAN and WAT are both suffixes used for WAN sprites. General Information The file is read from bottom to the top. This is likely because of the way the content of the file is organized, and how the files are meant to be loaded into memory and used as data structures right away. The content of the file is split in 5 categories. Meta-Frames The meta-frames are basically the virtual image that the animations are referring to. They're essentially an abstraction layer above the actual images, and contain data about these ranging from which image in the image pointer table a meta-frame refers to, the actual image's resolution, whether the image should be flipped vertically or horizontally, and even more. Meta-frames can be "grouped" together in a sequence, with the last meta-frame in a group being indicated by as special bit flag. This allows the game to combine several small images together, to assemble a bigger one. The Offsets stored in the meta-frame allow positioning the images to properly assemble them. The animations refer to each meta frame, even single ones, as a meta-frame group, via index. The location of the first meta-frame of a group is stored in the Meta-Frame Groups Reference Table. Image Data The actual images are stored as pixel strips, followed with an assembly table. The table contains a list of entries indicating how to rebuild the image. The main reason the images are stored that way seems to be to remove needless zeroes that normally make the bulk of most images. The table indicates in what order to insert either a pixel strip of a certain length, or to insert the specified amount of zeroes. All the lengths of the strips of pixels, or the amount of zero to insert is always divisible by 16. The format of the image data can be either 4 bpp or 8bpp, as indicated in the WAN Header. Animations Each animation is made up of 3 things, a group, some sequences, and some frames. The groups itself is the "handle" of the animation. You can label them with an action, like "Run" for example. For character sprites(non-character sprites or special sprites follow different rules), each groups has 8 slots, each slot refers to a sequence. One for each of the 8 directions of movement. Groups may refer to the same sequence in all their slots. In character sprites, specific groups across all sprites/characters of the same type, have all the same use. For example, all character sprites' first group in the list is always the running animation! Each sequence is a list of animation frames one after the other, terminated with a null frame. Each frames contains a display duration, the index of the meta-frame group to be displayed, an offset to move slightly the image relative to the logical center of the sprite, and an offset for the shadow blob displayed under the character. Particle Offsets Not much is known about those. They're a very long list of 16 bits signed integers, meant to be read 2 by 2. They indicate the offset to display particles, like sweat drops, along with exclamation marks and etc.. For now, its unknown how the game knows which is the correct one to pick for what. Color Data This contains the palette used by all the images in the sprite. It also contains details as to where to store the palette in video memory. Still not much is known about how exactly it all works, besides the actual color palette. Overview Here's an overview of how a WAN file is laid out. Offset Length Name Description 0x00 16 SIR0 Header The SIR0 container's header. The first pointer points to the WAN Header. The second to the SIR0 Encoded Pointer Offsets List. 0x10 Varies Meta-Frame Groups Block This contains all the meta-frames groups. After Meta-Frame Groups Block Varies Animation Sequences Block Contains all the animation sequences, and the frames that makes them up. After Animation Sequences Block Varies 0xAA Padding Bytes (If needed) Some padding to align the next block on an offset divisible by 4. After Padding Bytes Varies Image Data Block Contains all the image data. After Image Data Block Varies Color Data Block Contains the palette, along with some other color information. After Color Data Block Varies Meta-Frames Reference Table A list of 4 bytes pointers, containing the offset of the first meta-frame of every meta-frame groups located inside the Meta-Frame Groups Block. After Meta-Frames Reference Table Varies Particle Offset Table A list of made of pairs of 16 bits signed integers indicating offsets to display particle effects at. After Particle Offset Table Varies Animation Groups' Sequences Reference Table Several lists of 4 bytes pointers to animation sequences inside the Animation Sequences Block. Each list is pointed to by an entry in the Animation Groups Table. After Animation Groups' Sequences Reference Table Varies Animation Groups Table A list made up of a pair of 32 bits integers, one a pointer to a list of sequence in Animation Groups' Sequences Reference Table, the other a number indicating the length of that list. After Animation Groups Table Varies Image Data Pointer Table A list of 4 bytes pointers to the assembly table of every images in the Image Data Block. After Image Data Pointer Table Varies Animation Info Structure Contains info on, and pointers to the animation data. After Animation Info Structure Varies Image Info Structure Contains info on, and pointers to the Image Data Pointer Table, and Color Data Block. After Image Info Structure Varies WAN Header Contains 2 pointers to the the 2 structures above, along with a boolean indicating whether this is a prop, or an 8 way animated sprite. After WAN Header Varies 0xAA Padding Bytes (If needed) Some padding bytes to make sure the next block starts on an offset divisible by 16. After Padding Bytes Varies SIR0 Encoded Pointer Offsets List A compressed list of every pointer pointer offsets in the file. Used to translate file-relative pointers to NDS memory relative pointers. After SIR0 Encoded Pointer Offsets List Varies 0xAA End Of File Padding Bytes (If needed) Some padding bytes to make sure the file ends on an offset divisible by 16. WAN Header The header is made up of 3 parts. The first part is just a little chunk of 12 bytes with two pointers to the 2 main parts of the header. It also contains a boolean that indicates whether the sprite follows the same format as character sprites or not. The animation info block contains various information related to how to animate the sprite, and where the various required elements to animate the sprite are located in the file. The image data info block contains details on the format of the image data stored in the file, along with the color data that all images in this sprite uses. Main Header WAN main header. (Total length 12 bytes) Offset Length Endianness Type Name Description 0x0 4 little uint32 Ptr to Anim Info A 4 bytes pointer to the part of the WAN header containing data on the sprite's animations. 0x4 4 little uint32 Ptr to Image Data Info A 4 bytes pointer to the part of the WAN header containing data on the sprite's images data. 0x8 2 little uint16 Sprite Type A 2 bytes integer value to indicate what kind of sprite this is. Known values are 0,1,3. Or Props/UI, Characters, and Unknonw, respectively. 0xA 2 little uint16 Unknown #12 Unknown purpose. Referred to as Unknown #12 for now. Animation Info Animation info block. (Total length 24 bytes) Offset Length Endianness Type Name Description 0x0 4 little uint32 Pointer to Meta-Frames Reference Table A 4 bytes pointer to the Meta-Frames Reference Table. 0x4 4 little uint32 Pointer to Particle Offset Table A 4 bytes pointer to the Particle Offset Table. This can be a null pointer, only for type 0 sprites! (UI sprites, and props) If a type 1(character sprite) sprite has no particle offsets, the pointer's value points to the end of the Meta-frame table. 0x8 4 little uint32 Pointer to Animation Groups Table A 4 bytes pointer to the Animation Groups Table. 0xA 2 little uint16 Amount of animation groups The amount of animation groups in the Animation Groups Table. 0xC 2 little uint16 Unknown #6 (Uncertain)Possibly the amount of blocks(groups of 4 tiles, possibly ?) allocated for the image in video memory. 0xE 2 little uint16 Unknown #7 Unknonw purpose. 0x10 2 little uint16 Unknown #8 Unknonw purpose. 0x12 2 little uint16 Unknown #9 Unknonw purpose. 0x14 2 little uint16 Unknown #10 Unknonw purpose. Image Data Info Image Data Info block. (Total length 16 bytes) Offset Length Endianness Type Name Description 0x0 4 little uint32 Pointer to Image Data Pointer Table A 4 bytes pointer to the Image Data Pointer Table. 0x4 4 little uint32 Pointer to Color Data Block A 4 bytes pointer to the Color Data Block. 0x8 2 little uint16 Unknown #13 (uncertain) If 1, load the first row of tiles of each images one after the other, the the second, and so on. Seems to be for very large animated sprites! 0xA 2 little uint16 Is 256 colors 8bpp A boolean value indicating whether the sprite's images should be written to video memory as 8bpp, 256 colors images. If its 0, the images are written to memory as 4bpp, 16 colors. The game can write a 4bpp image as a 8bpp to video memory properly, but the palette needs to be moved to the extended palette area, possibly by messing around with other values. Another value in the color info block needs to be set for any of this to work properly! 0xC 2 little uint16 Unknow #11 (Uncertain) Seems to move the palette around palette slots in the video memory. 0xE 2 little uint16 Amount of images The number of images in the Image Data Pointer Table. Image Data Pointer Table This is a very simple list of 4 bytes pointers to the assembly table of every image in the file. The amount of pointer in this table is specified in the Image Data Info block. Animation Groups Table A list of entries, each representing an animation group or "action". For characters, this table is usually 13 entries long, for hero/partner characters, it is at least 35 entries long. For non-character sprites, the length varies. Each entry is 8 bytes long, and made up of 2 values. The first is a 4 bytes pointer to the beginning of the list of sequence slots for this particular group in the Animation Groups' Sequences Reference Table. The Second value is a 4 bytes unsigned integer indicating the number of slots in the list, pointed to by the first value, for this particular group. Entries may be completely null, and if that's the case, there must be a corresponding null pointer in the Animation Groups' Sequences Reference Table. For example here's a typical group table( converted to big endian, as 4 bytes values, and displayed 1 entry per line! ): 0x00004AEC, 0x00000008, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00004B20, 0x00000008, 0x00004B40, 0x00000008, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00004B70, 0x00000008, And the corresponding sequence table( laid out to better where are the sequence lists for each of the groups in the group table above starts and ends ): 0x000002D6, 0x00000312, 0x0000034E, 0x0000038A, 0x000003C6, 0x00000402, 0x0000043E, 0x0000047A, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x000004B6, 0x000004DA, 0x000004FE, 0x00000522, 0x00000546, 0x0000056A, 0x0000058E, 0x000005B2, 0x000005D6, 0x000005FA, 0x0000061E, 0x00000642, 0x00000666, 0x0000068A, 0x000006AE, 0x000006D2, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x000006F6, 0x0000076E, 0x000007E6, 0x0000085E, 0x000008D6, 0x0000094E, 0x000009C6, 0x00000A3E, Notice how each null groups in the group table has a single corresponding null pointer in the sequence table below. Animation Groups' Sequences Reference Table As mentioned above this is simply a list containing pointers to animation sequences. Each entries can be though of as a slot assigned to one of the groups in the animation group table. The length of this table is determined by adding up the amount of animation sequence slots for each entries in the animation groups table. Taking care to count completely null groups as 1! Particle Offset Table Not much is known about this part. It can be completely omitted in non-character sprites. It basically contains coordinates, offsets from the center of the sprite where to display particle effects. Things like sweat drops, exclamation marks, or battle effects. The length of this block varies indiscriminately from pokemon to pokemon. Hero/Partner pokemon have more entries than other pokemon. Its unknown how the game finds what coordinate to use for what. It might be stored in another location in the game's file system. Meta-Frames Groups Reference Table This is another very simple pointer list, pointing to the first meta-frame of every meta-frame groups in the file. Color Data Block Image Data Block Animation Sequences Block Meta-Frame Groups Block Credits Thanks to TruePikachu for finding out the link between the various parts of the file format!
  10. psy_commando

    SRL File Format

    In Pokémon Mystery Dungeon: Explorers of Sky, this file format contains a ROM image of the DS Download Play demo that can be shared with others via the main menu. Explorers of Sky is the only out of the 3 "Explorers of" games to have those in its "/SYSTEM/" directory. One can simply rename the file, changing its extension to ".nds" and load the file into any NDS emulators as if it was a regular ROM image!
  11. I checked those in the zip with irfan viewer, and they're 256 colors 8bpp pngs, they should be 16 colors 4bpp pngs. There are 16 colors in the palette, but the format is still 8bpp 256 colors, and that's the problem. And, I think at this point, it might be better/faster if you guys used PMs to solve this. Sorry for changing my mind, but its been going on for almost 5 pages this far, and I think we pretty much dealt with all the potential bugs with the program now. ^^;
  12. General Information This page contains data on the Pokémon Super Mystery Dungeon game. File Structure Script Engine Details The Script engine of PSMD uses compiled lua 5.1 scripts. List of all function, objects, and globals : Here File/Data Formats Most files formats are identical to the ones found in Pokémon Mystery Dungeon : Gates to Infinity. However, some have been updated, added, or differ slightly. Container Format BIN(FARC) Image Data IMG Game Strings BIN(GameStrings) Script Engine Formats LUA Files with Unique Formats External Resources
  13. I seriously doubt that SIR0 is only for configuration though. I've seen plenty of images, archives, compressed stats data, and etc that were wrapped into a SIR0 for no apparent reasons in the past. Especially in PMD:Explorers of Sky. It seems to me like its just a way to load any constant data structures at runtime directly into the 3ds's memory, and have the code use it as-is from an arbitrary memory position. (And its really easy to crash the game and writing in a lot of places you're not supposed to with that file format A single error in the encoded pointer list is enough to corrupt most pointers after they're translated, and thus write pretty much anywhere in the allocated user space memory. I made a mistake once, and the game began writing into the OAM, or maybe even the video memory, and things started looking pretty crazy on-screen ) And about the different types of FAT, 2 types sounds about right. I've only seen 2 variations so far. (for models files at least) But it depends on what you want to do. Are you writing a FARC extractor, or something else ? Because, there are probably a lot of variations of the SIR0's content around. Nice work with those FARC files ! Interestingly, the message_debug.bin archive seems to contain many "string database" files that were used in GTI. They all seem to match my notes : https://dl.dropboxusercontent.com/u/13343993/my_pmd_research_files/PMD_GTI/FileFormats/string_database.txt But the message.bin seems to contain those too, only the strings that each pointers refer to isn't in the SIR0 container itself.. I wonder what this means.. (I only got the Japanese ROM right now though ) What's even more intriguing is that, the function used to load the game strings for menus still refers to the "message" directory, which is missing in PSMD. MENU:LoadMenuTextPool("message/staff.bin") So, I'd guess, they modified that to pull text from somewhere else ? Possibly involving that message.bin file ? EDIT: Also, nvm about the strings missing from the string files within the message.bin file.. Its a bit too early for me to say I guess.. There's a possibility that UTF characters don't show up properly in my hex edtior, and well, I think I'll have an easier time once I can dump my NA rom.. ^^; And the message.lst file seems to contain the file names for the "string database" files within the message.bin file ! Or at least, that's what I'm assuming.
  14. That console output you got with your tool, from what file is it ? Did you find out to what the offsets in the file allocation table are relative to ? I'd guess they're relative to the data blob that comes afterwards, but it wasn't all that conclusive from taking a very quick look at it. And sorry if I'm having a bit of difficulty understanding what you mean. In other news, I'm getting oot3d hax soon. So I'll probably be able to do a lot more with this game once I get HANS and everything setup.
  15. I never heard of gdkchan before. Also, SIR0 isn't a consistent format. Its just a wrapper for importing data structures as-is into memory and translating the pointers. So you'll have to go by filenames if you want to differentiate them. For example, what's labelled as "pointer table" is literally a header with a fourcc and all in some cases. Like in the pokemon_graphics_database.bin file for instance, or several other file formats in PMD:EoS. ( Knowing myself I probably called it pointer table on the wiki as well ) But, what's causing you issues then if you can export some of the files ? Could you tell me a bit more ? Like, what gets extracted correctly and what doesn't ? I could probably figure something out much faster if I can just look at specific part, instead of having to reverse the whole thing first.
  16. Posting textures is nice, but this is a research thread, so it would be appreciated to actually share notes/info over sharing ripped assets as much as possible. ^^; And thanks, I'll take a look at those files.
  17. You'll have to point me to what bin contains CGFX. I remember seeing that somewhere but I can't find it. Also, is that in GTI or PSMD ? And, I'm looking for data on regular BCH models files actually to figure out the "bgrs" format. So if you have any to share that would help. Some people have claimed they could get models out of the game by the Japanese release date, so that wasn't exactly a priority for me personally this far. But then again, the people I heard that from don't really seem all that reliable either.. And if you're looking for file lengths and offsets, they're most likely stored in the sir0 at the beginning, or in the pokemon_graphics_database.bin file. Chunsoft are known for loving their customized file formats though, so I'm not really surprised they deviated from the usual format.. At least, they pretty much use 0 compression in this game thankfully.. The SIR0 format is a blessing for reverse engineers though. The encoded pointer list at the end lists all file pointers within whatever is inside the SIR0, so it makes it easier to guess what's a pointer to something in the file/memory or not. EDIT: Here's a handy little tool for converting the ptr offset list quickly to something human readable : https://dl.dropboxusercontent.com/u/13343993/my_pmd_utilities/sir0_ptroffsetdecoder.zip Just dump only the encoded ptr offset list into a file, as binary data, and drag and drop that onto the batch file, and the utility should output a list with all the offsets(from the start of the SIR0 header) the pointers are at within the SIR0. Its not really meant to be used for anything else than research though. Also, data on the SIR0 format is on the wiki, and its linked in my first post in this thread.
  18. Its fine, "don't quote me on that" is just an expression to say "I might be wrong". You can quote me if you want But yeah, I think your best short-term bet might be to ask the people working on the model tools for ORAS and etc first. Then, if they don't support this model format, it will take us a while to reverse it and be able to actually rip the models.
  19. Those missions are probably just enabled by that code, they're most likely not contained in it.. As far as I know, wondermail passwords have always had an encoding and a syntax. Like the 20 apple thing, there's probably a part of the password that sets the type of password to give you items, the amount of items, and the actual item. But it doesn't mean they contain entire level data and etc. By "code", what do you mean exactly ? Like identifiers/translation table ? Or did the way wondermail work changed since PMD2? Oh, so you guys were talking about a list of individual passwords to get each items and etc ? I guess I took this a bit too literally then Don't quote me on that, but some have claimed the models are in BCH format. I still need to verify that on my end. We'll eventually get to extracting/importing animations and textures, and etc.. Though, I think most of us haven't finished the game yet, and probably some of us don't want to get spoiled ^^; EDIT: Nevevmind that about models. They're identified as BGRS files. in the pokemon_graphics_database.bin file. I don't know if its any similar to existing formats though.. But from the looks of it, you need to look up model files in the pokemon_graphics_database.bin file, and get them in the pokemon_graphic.bin file. I don't know if existing tools do that. Feel free to correct me if I'm wrong though. I appreciated the information.
  20. Passwords aren't stored. They're interpreted. And in order to make our own passwords to get whatever you want from those, someone needs to decipher the way they're made/interpreted. See the wondermail generator for pmd2 for example. Though, that's not really our priority. We're pretty much just taking apart file formats at this stage. And, personally, Idk how I'd go about reversing passwords without a decent debugger+emulator. You probably want to look up gamefaqs, bulbapedia, or serebii. Because, its possible we'd find mention of those, but it wouldn't mean they'd be in-game. Besides, its going to take a while before most of us are done with the game, and/or get their hands on a decrypted US rom of the game.
  21. PSMD is out in north america ! I got my copy and I'm now around chapter 12. Its an awesome game, and a worthy successor to Explorers of Sky in almost every ways, for those wondering! Its nothing like GTI, even though it re-uses the same engine ironically. So whenever I finish this game, I should be ready to take it all apart without fearing for spoilers! Also, I think evandixon has been working on some pretty nice stuff for handling eventual romhacks. But he'll probably drop by to talk about those himself eventually. And I completely didn't meet my objective of getting a portrait utility out. But, at least now I mostly fixed my repository, and the PMD3 projects. I'll also drop compilation to DLL for pmd3 projects for now, because it was a dumb idea to begin with, and most of our research notes aren't set in stone yet, soo.. I'm also still looking for a way to document the game's Lua scripts. So if anyone has an idea for a way to do this with a tool or something, feel free to suggest! Still couldn't find a cubic ninja copy, and now all cubic ninja games are around $100 CAD. So I'm considering getting a sky3ds instead, since its cheaper.. ( If only I could get MGS5 refunded ^^; )
  22. At this point, she probably should start playing the game like that. Its going to take a while. And we're both a bit busy right now ^^; The save game can always be re-used with a modified rom.
  23. I doubt its that different though, maybe a single line of differences? But if you got the sources, you can easily build it and test it with a up-to-date pdb. Just use the ppmdutilities_dependencies project to build the libraries, then just build kaoutil and set whatever command line argument in the project settings under debugging. I just realized that, the output might be not printed at the right moment because the compiler might have optimized things out.. Ugh.. Anyways, at least I can say that, it either crashes during decompression, or while trying to access whatever got decompressed. So it seems to hint strongly at corruption.. Are you sure something weird isn't happening when the patcher patches/rebuilds the game? Because I can't get it to happen by just using kaoutil over the repacked kaomado.kao.. Yeah, I'll probably be busy friday too My copy actually just shipped today ! Lets just hope it won't force upgrade my firmware though.. ( Speaking of that, I've tried emailing a few small used game stores for cubic ninja, but they all seems to say "not available" ) Well, if you want, you can also just sent it to me over skype. ( And I saw that pooch )
  24. We're not sure yet what's going on. I'm waiting to hear back from evan first. It might be something weird about the language/version of your rom, but its a bit too early to say..
×
×
  • Create New...