Leaderboard

Technically any method can happen at any time. Static encounters rare have anything other than Method 1 since it doesn't use animations (splash, rocks, grass, etc) nor does it load separate music. The longer the animation (generally stuff that cause vblanks) the more likely a method 2/3/4. Forcing a nature (syncing) will increase method 2/3/4 because of nature confirmation (rolling for a PID that matches the nature sync). H (no idea why that letter) IIRC is the designation for spreads specifically for wild encounters via random chance. A wild encounter is grass/surf/caves/power plant. The order from seed for wild encounters goes similar to this: Should encounter? Which encounter slot? Which level? Which nature? (Or Sync, or swarm, etc) Roll PID until nature matches (many times there is a vblank here) IV1 IV2 Held Item Static encounters, gifts, and rod are not wild encounters. I don't even think gifts have nature confirmation. Fishing is weird cause it's like a wild encounter minus the change of the encounter occurring. I am not sure if it's lumped under H or not, but if it is, that's superficial imo.

out of genuine curiosity, what use for that is there?

Hi, the use of each method should be as follows: 1: all stationary encounters(starters, gifts, legends, etc.), for ALL Gen 3 GBA games played on a GBA; H1: wild encounters(including the use of sweet scent) for Ruby, Sapphire, Fire Red and Leaf Green; H2: wild encounters(including the use of sweet scent) for Emerald. Sometimes, however, it can shift to method H1/H4, expecially with some kinds of encounters, like fishing; 4: stationary encounters(most of times, at least) for Ruby and Sapphire played through Pokemon Box; H4: wild encounters(including the use of sweet scent) for Ruby and Sapphire played through Pokemon Box. The shift to this method is not guaranteed, however: it only happens to be more likely when playing Ruby/Sapphire via the Gamecube. Method H1 and H4 spreads are the same of method 1 and 4 spreads, respectively; they are just adjusted for wild encounters. This means that a PID obtained with method H1/H4 also exists for method 1/4. I never got a method 2 or a method 3/H3 spread. Colosseum/XD and Channel follow their own method. I can confirm that the results are the same for both a regular console and the emulator I use(VBA-RR). I hope this was of some help.

Hey! So, swdl format issue. I apologize if this is the wrong place to discuss this, or if this has been brought up before. I did a quick scan of the various docs and notes and didn't see any mention of this, so I thought I'd go ahead and post on the off chance that someone hasn't come across this yet? I've been writing a little ROM explorer for funsies - thought I'd add a swdl/smdl player since I already had a makeshift but working synthesizer and player GUI as well as code for handling smd files (a couple years back decided to do a dump of the EoT BGM to midi because I like messing with the sequences in protools). Getting to the point, the issue is with sound sample tuning. I've been using Apple Woods (bgm0025) as my test track. This is the creepypasta reject I get when playing it: rotten_apples.mp3 I think my interpolator still has some problems, but does play back sseq/sbnk and playstation seq/vab songs without any tuning issues. The most glaring source of the discord I have tracked back to Programs 52 and 53 in bgm0025.swd (which are identical except for the envelopes, I think 53 is the main one and 52 is used for delay tracks). Tabled the tuning values (as read from the fields specified by the https://projectpokemon.org/docs/mystery-dungeon-nds/dse-swdl-format-r14/) for all the non-percussive programs in bgm0025.swd: Included Polyphone's suggested tuning in the last two columns (dumped to sf2 so I could play with tuning directly). It's prone to being wrong on the octave of the root key, but its fine tune suggestions do seem to be pretty close to the actual notes (once root key is corrected for). No coarse tune in Polyphone suggestions. So here's the weird thing I'm confused about. When I modify the "coarse tune" and "fine tune" fields in the file directly on the ROM and run it through an emulator, I get the exact same results as yall - 0x14 appears to control fine tune by cents and 0x15 appears to control coarse tune by semis. But applying the same parameters to an external player does not produce accurate playback. In fact, in the sf2 dump I generated programs 52 & 53 don't even have continuous regions pitch-wise? It's pretty weird. Yet it seems pretty clear that when I modify these fields and put them back in the game, the tuning is affected by about the amounts changed? And then there's the fact that the default coarse tune is -7st, but the song does not play 7st lower than the sequence? I'm wondering, are there values stored elsewhere or loaded with the driver that scale the tuning somehow? I didn't see any obvious currently unknown values in the swd that could be candidates (most unknown bytes are 0x00 or 0xaa), but I'll probably look again. Hoping to probe into it more this week once I get some quality sleep and some more stuff for work projects done. But if this is something that's already well characterized that my tired brain just skimmed over, absolutely feel free to just point me to the appropriate documentation/notes instead! Again, sorry to sort of throw off the groove of this conversation, but this seemed the most prudent thread to bring it up. Feel free to delete it or move it if you need ! EDIT: Got it. Sort of. Seems to be a low level value telling the player how to tune it to the root note relative to the stored sample rate. For a high level smd player, this value can be completely ignored as the weird sample rates of the values account for the fine tuning already. I did try mapping it as one byte coarse tune and one byte fine tune relative to the sample rates and it doesn't quite add up, so wondering if it's a 16-bit LE value meant to be loaded into a voice control register or used directly by the driver? I soooo don't know, I'm just throwing stuff out there. Anyway, that's that. Just thought I'd note that here in case anyone else happens to have the same issue.