Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by psy_commando

  1. Abilities are just code. You'd have to edit the asm to do it. There might be some special characters or space in the path to your desktop.
  2. Nice! That's pretty impressive! Do you happen to have some documentation on this? Having the source is nice, but it takes a while to dig through.
  3. SED files are a bit more complicated. I haven't done much with them. But maybe eventually
  4. Not yet. But we do know how most of it works. We still need to write tools to do it. Tilesets are still tricky. Well, you can rip the individual samples inside a SWD file to wavs using my tool.
  5. You could also just go into the routine in the common script that runs the new game start and plug in the scene you made. I think you can skip the personality quiz too if I remember correctly.
  6. Just to add to this. The XML outputed is in a very similar structure the data inside the script files, its just a bit more organized. So the details on the script op codes in my notes and etc work with those as well.
  7. Well, I think fl studio's midi import was meant more for importing stuff from your typical music notation software that doesn't do anything very fancy with the midis. Roland's GS is an extension on General midi, same with Yamaha's XG, that tried to add missing features to it, but they're their own standards afaik. But, yeah, lots of things done via sysex messages aren't GM standard. Although GS, or at least some parts of it like some of their extra instruments, kinda became more or less commonly supported outside the standard from what I know/can see. So its really a huge headache to deal with midi compatibility XD
  8. @xusu I had been planning to release a version of the program that exports one soundfont per track to help with this kind of things. One per track mainly because samples are tuned differently for every single tracks. I never really got around to it, since the whole thing is a broken mess really. Don't use -gm. It won't work well with pmd2 since the tracks have several percussive tracks, and some just don't. GM expects track 10 to be drums always, GS doesn't. The game also never uses more than 16 tracks, so don't worry about it, the default mode will always have 16 tracks max. I think your problem with the chromatic/percussive tracks not switching modes properly comes from how the FL studio sequencer doesn't seems to handle importing/converting sysex midi messages. My tool puts in each midi file some sysex messages to tell the synth to run in GS mode, and set some tracks to chromatic/percussion tracks. A bunch of older synths, like windows' default built-in synth don't support that. So you'll probably have to change those things manually when you import it in FL studio since its midi import is far from perfect. Also, I suggest you dump the raw pmd2 samples using this line : "EoSRomRoot/data/SOUND/BGM/bgm.swd" "out_pmd2samples" -hexnum And then export the list of sample used for each presets for each tracks: -swdlpath "EoSRomRoot/data/SOUND/BGM/" "out_pmd2samples.txt" -listpres -hexnum Then if you compare the cv_info file and the out_pmd2samples.txt files for each tracks you'll see what samples each track/instrument presets uses, and can listen to each individual samples exported from the soundfont. That's how I did to figure out what samples are what. It really helps a ton, since the game's soundtrack messes with the samples a lot with effects and etc. For instance, in treasure town, if you listen to the samples you said are bagpipes, they don't sounds at all like bagpipes. The composer just layered several notes to sound like a bagpipe. But in other tracks, those very same samples are used for something that sounds closer to what sounds more like an English horn or something close to it, maybe a bassoon or some "non-standard" variation that sounds like that. The actual bagpipe samples are used in bgm134 and 137 for example. Also, some of the instrument samples used in the game are instruments not in general midi or gs. Some percussion(like that Indian percussion in track#29), and etc.. So I put what was closest. About your earlier questions: 1. About the cv_info file, to change the midi instrument used for a given in-game instrument/preset just set the number in-between the MIDIPreset tags to the preset number you want. Like: <MIDIPreset>81</MIDIPreset> You don't need to touch the DSE preset. The tags are explained at the top of the cv_info file too. 2. That's because of FL studio's Fruity LSD does not support GS sysex messages, or basically any sysex message afaik. Better use something more compatible like foobar2000 or the bassmidi driver, or anything based on fluidsynth to play the midi with a GS compatible soundfont and you'll notice the drum/chromatic tracks are fine.
  9. Its fine, the whole point of this thread is to be bumped every once in a while! XD I'm not really sure what you're trying to do? The xml file is for remapping PMD2's instruments to GM/GS when doing a midi only export. It has no effect when exporting the tracks along with their soundbank. And when you say the wrong instrument is set, what do you mean? In the midi-only rips or the soundfont, or in the midi files that accompany the soundfont? Adding the -gm option on the command line just tries to make it so old GM only software has a better shot at playing it back by swapping any existing drum channel with the right one. By default the files are all exported for a GS compatible midi driver. GS allows things like disabling the drum channel as needed and etc.. The way DSE works is similar to GS and not GM. Which means some tracks just won't work when exporting as GM since they use the drum channel as a melodic channel.
  10. You can't just use that on the rom file. You need to extract the content of the rom and use it on one of the pack files that's listed in the readme. But even then, this tool is mainly meant for researchers/toolmakers since it doesn't do much besides unpack some bin files into its sub-files.
  11. If I remember correctly, missing assets/not precached assets makes the starter select screen crash. I remember testing some changes at one point and you ended up testing them? Also, all the starter models are all on the select screen and get unhidden depending on the pokemon #. Basically adding starters to GTI is a lot more involved than PSMD.
  12. Nope, GTI works very differently inside. There's stuff in the works for it though! Both PSMD and GTI are very similar, so mod tools for one will most likely work for the other. @evandixon got some tools working for those too!
  13. Well, 0x4 in a pokemon's entry changes its displayed dex id. I don't think it has anything to do with evolution. And that's possible. I know that shaymin is also another special case that's handled in the code. And glad it was useful! ^^
  14. I'm not sure what you mean? The sprites for each pokemon are stored inside "m_ground.bin", "m_attack.bin", and "monster.bin", under the data//MONSTER directory. Each of those 3 files contains one of the 3 parts of each pokemon's animations/sprite. All pokemons have an entry in all 3 files. m_ground contains the sprites on the overworld/ground mode. m_attack the attack and dungeon animations for the pokemons. And monster the enemy sprites, which are just stripped down versions of the m_attack sprites to save memory on enemy pokemons.
  15. Just drag and drop the "m_ground", "m_attack", or "monster" on the gfxcrunch executable. It'll export the content to a folder. Then do your changes to the folder, and drag and drop the folder on the gfxcrunch executable. But I'm working on a sprite editor currently to supersede gfxcrunch.
  16. Use the batch files. Or SHIFT + right click with nothing selected on the background of the folder with the program in, and click on "open command prompt here" then look at the command lines examples in the readme.
  17. Well they're in the rom. You have to extract the rom, then look under data/FONT/kaomado.kao. You can use the batch scripts for doing that automatically too. Then you have to rebuild the rom with the modifications. Think of a ".nds" file as a zip file really. Except you need something else than winzip/7zip to extract/rebuild them. Well, its mainly about finding the UI API functions in the code, then hooking in your modified code. Its not that hard, but it takes time and patience. Especially if you're doing it by hand instead of using something like Radare2 or IDA. And yeah, I plan to release a bunch of QoL asm hacks eventually. I got some done already on my github mainly to load map lists from file and etc.. In order to make modding easier. I'll probably dive back into that eventually, once I can fix my utilities and get to the big map editor I'm planning. You could already fix the sleeping animations though. You'd need to basically copy in the missing sleep anims it looks for from the dungeon sprites into the ground mode sprites for the specified pokemons, and it would work.
  18. Well, it might be possible. But not without some ASM hacking. Right now I don't think we know enough to do it easily. But that could be a possibility.
  19. Well, I mean the unknowns are things I don't know about for the most part. But you seemed to be detailing the overall file structure of the waza_p file, and that's something I already know about and is pretty well documented in my notes and on the wiki. I appreciate the help however.There are still lots of things that weren't investigated yet though. If you wanna play around with script engine commands and figure out what they do, or mess with dungeon data, find reward lists offsets and etc.. There are still a lot of things like that.
  20. @Zerea Yeah, a lot of this I already knew. And I don't recommend removing move xml files when rebuilding them with statsutil right now, since its undefined behavior. I read your posts, but I'm not really sure what you were asking/saying? Sorry. Great! Thanks for the info! I could reproduce the crash, but I'm not really sure what's going on.. I'll have to take a closer look. Seems like it crashes in release, but is completely fine in debug... Looks like its gonna be one of those bugs..
  21. Well, my assumption had been that those were bitfield, aka the game would check for the value of a specific bit to toggle something on or off, but it could also be an enumeration.. I used to modify those bitfield in memory while running the game, and it seemed to me that unk#4-5 values both contributed to the resulting effect of the move. Like unk5 seemed to affect ranged move particularities.. I took some notes from your analysis, but I think it might need some testing to see how it works in practice?
  22. Thanks for the data! I was pretty sure it had to do with critical chance, but I wasn't sure if it was a ratio or something else! And you're not derailing anything, this thread was meant to share research results and etc, so you're welcome to post any findings you wanna share! ^^
  23. Well, like most data stored in SIR0 files, its all meant to be loaded as an array in memory. I haven't yet looked into how the indice for special items is obtained though. But technically, if the item array size isn't hardcoded, you should be able to just refer to the new item ids in the dungeon and shop data spawn lists. But I have yet to make a tool for that, because a bunch of those are hardcoded in the game executable. I've managed to mod the game's binary in the past to load a variable size map list with some asm edits, so I figure I should be able to mod the game to put those lists into files as well. But I'm working on other stuff for now.
  • Create New...