Gridelin Posted May 20, 2018 Share Posted May 20, 2018 2 hours ago, Deoxyz said: It wasn't mail-in in 2005 during the original events. It's just that Nintendo of Italy continued to provide a service on their website up until a few years ago (or still?) for players to mail them their carts. That's how we had all the wondercards dumped a few years ago. But regardless the cart/rom could have leaked just like any other cart, originating through employees themselves. They unfortunately stopped the service in 2015-2016 sometime. I had some friends that did a semester in Italy and probably got some of the last cartridges sent in before they ended the program. Also, somewhat related, has anyone else noticed how few demos/distro cart style things get leaked from Japan? I feel like Nintendo of Japan's culture makes leaking things of that nature almost unheard of. 1 Link to comment Share on other sites More sharing options...
theSLAYER Posted May 20, 2018 Share Posted May 20, 2018 1 hour ago, Gridelin said: They unfortunately stopped the service in 2015-2016 sometime. I had some friends that did a semester in Italy and probably got some of the last cartridges sent in before they ended the program. Also, somewhat related, has anyone else noticed how few demos/distro cart style things get leaked from Japan? I feel like Nintendo of Japan's culture makes leaking things of that nature almost unheard of. I speculate: Perhaps all their event carts are locked down, so an employee can't tamper with it, with the purpose of dumping the rom. Also, there is likely a system that keeps track of every employee that was in-charge of the device (sign-in sheets probably), and if so, they'll know who stole the device, and force the information out of the employee (if sold off). Even if it was stolen from the employee, I would imagine the market for such items aren't public, and any collector there whom purchased it would probably try to keep it private and in "mint condition". (Any public sales may lead to ninty tracking it down and repossessing it) Furthermore, I think the employee involved in this would get fired, and potentially end up unhire-able, so it's simply not worth the risk. (additionally, the units distributing birthday Pokemon in Jp right now, are cable-chain locked to the desk, if I'm not mistaken. I would imagine such safeguards are a thing in Japan) 2 1 Link to comment Share on other sites More sharing options...
YoshiMoshi Posted May 20, 2018 Share Posted May 20, 2018 7 hours ago, Gridelin said: They unfortunately stopped the service in 2015-2016 sometime. I had some friends that did a semester in Italy and probably got some of the last cartridges sent in before they ended the program. Also, somewhat related, has anyone else noticed how few demos/distro cart style things get leaked from Japan? I feel like Nintendo of Japan's culture makes leaking things of that nature almost unheard of. Agreed. You must also consider, that the distributions that are pokemon center only, I think there's like what currently 11 pokemon centers in japan, so assuming one distribution device/cartridge per store (what's the need for more for wireless distributions, than that would mean only 11 of those devices ever being created, ever, chances are essentially zero of leaking, would be very easy to see who didn't return the cartridge. I doubt we'll ever see a japan distribution cartridge/device. I also heard that crime is very low in japan, as a cultural thing 6 hours ago, theSLAYER said: I speculate: Perhaps all their event carts are locked down, so an employee can't tamper with it, with the purpose of dumping the rom. Also, there is likely a system that keeps track of every employee that was in-charge of the device (sign-in sheets probably), and if so, they'll know who stole the device, and force the information out of the employee (if sold off). Even if it was stolen from the employee, I would imagine the market for such items aren't public, and any collector there whom purchased it would probably try to keep it private and in "mint condition". (Any public sales may lead to ninty tracking it down and repossessing it) Furthermore, I think the employee involved in this would get fired, and potentially end up unhire-able, so it's simply not worth the risk. (additionally, the units distributing birthday Pokemon in Jp right now, are cable-chain locked to the desk, if I'm not mistaken. I would imagine such safeguards are a thing in Japan) It makes me wonder how the Japanese aura mew distribution and 10 ANNIV cartridge got leaked 1 Link to comment Share on other sites More sharing options...
Deoxyz Posted May 20, 2018 Share Posted May 20, 2018 7 minutes ago, YoshiMoshi said: It makes me wonder how the Japanese aura mew distribution and 10 ANNIV cartridge got leaked There's no Japanese Aura Mew, but I'm sure you just mistyped that. They probably got leaked through Nintendo employees. The distribution devices were likely pretty much always in possession of the event team handling the distributions. I don't think theft from the distribution locations was a possibility until the mass produced carts appeared during Gen IV and V. Because by then any random GameStop, etc employee could take it when the event was over. 2 Link to comment Share on other sites More sharing options...
YoshiMoshi Posted May 20, 2018 Share Posted May 20, 2018 4 hours ago, theSLAYER said: (additionally, the units distributing birthday Pokemon in Jp right now, are cable-chain locked to the desk, if I'm not mistaken. I'd love to see a picture of this lol! Link to comment Share on other sites More sharing options...
theSLAYER Posted May 21, 2018 Share Posted May 21, 2018 6 hours ago, YoshiMoshi said: aura mew distribution and 10 ANNIV cartridge got leaked 6 hours ago, Deoxyz said: There's no Japanese Aura Mew, but I'm sure you just mistyped that. Technically speaking, Japanese "Aura" Mew would be Hadou Mew, lol. But yeah, Hadou Mew distribution wasn't leaked, it was Aura Mew (international). These get leaked possibly because: 1. The carts get moved around, to be brought to event venus (unlike being situated at Pokemon Centers)2. Maybe some disgrunted staff took them from a warehouse post event (when it wasn't a focus anymore), and wasn't destroyed after events. In my mind, both points are similar to how the NDS distribution carts always end up getting leaked. except the production of these are a heck load higher, as described by Deoxyz. 2 hours ago, YoshiMoshi said: I'd love to see a picture of this lol! Back from when our staff @ReignOfComputer went to Japan (more images here and here) 1 Link to comment Share on other sites More sharing options...
Sabresite Posted May 21, 2018 Share Posted May 21, 2018 Even though Hadou and Aura are the same name, the distribution software was different. Lots of reasons for why that is. 2 Link to comment Share on other sites More sharing options...
Guest Posted May 21, 2018 Share Posted May 21, 2018 (edited) This is Off-Topic... but I would like to add that PokePark Mew and Mystery Mew were both based on the Hadou Mew software. We know this because the OT Gender randomization is identical and they were all very likely seeded XORing the save file section checksums.Trash Bytes are identical as well. I personally believe that GCEA and all events that followed after were built on the Hadou Mew software as well... but this will probably never confirmed unless we get more roms. In relation to this Topic I have added a lot more content to the first post of the Thread, including the official sample scripts in readable form. Be sure to check out! Only stuff that's still missing is information about the Berry-Structure and Trainer-structure. Also thanks to @BlackShark who has provided a lot information in the past in this Thread which was very helpful, if there is anything more related that could be added let me know and I will edit it into the first post. Edited May 21, 2018 by ajxpk Link to comment Share on other sites More sharing options...
BlackShark Posted May 21, 2018 Share Posted May 21, 2018 @ajxpk e-Reader Trainers Spoiler e-Reader Trainer Data Structure (188 Bytes) Save offset: RS 0x498 (Section 0) Em 0xBEC (Section 0) FRLG 0x4A0 (Section 0) RAM offsets: English, French, German, Italian, Spanish RS 0x0202533C E 0x02025640 FRLG 0x02024A28 Japanese RS 0x0202509C E 0x020252E4 FRLG 0x02024988 --------------------------- 0x00 - Battle Tower Type 0x01 - Trainerclass sprite indexes differ between the game versions 0x02 - Battle Tower Lv 0x00 => Lv 50; 0x01 => Lv 100 0x03 - 0x00 0x04 - Trainer Name RS (US/EU): up to 7 Bytes + string terminator 0xFF RS (Jap), FRLG & E: up to 5 Bytes + string terminator 0xFF 0x0C - Trainer ID default: 0x0000 0x0E - Trainer SID default: 0x0000 0x10 - Intro quote 6 x 2 Bytes 0x1C - Win quote 6 x 2 Bytes 0x28 - Lose quote 6 x 2 Bytes 0x34 - 1st Pokemon 44 Bytes 0x60 - 2nd Pokemon 44 Bytes 0x8C - 3rd Pokemon 44 Bytes 0xB8 - Checksum 4 Bytes (all 184 Bytes of the trainer data added together as words) Pokemon structure (44 Bytes) 0x00 - Species 2 Bytes 0x02 - Item 2 Bytes 0x04 - 1st Move 2 Bytes 0x06 - 2nd Move 2 Bytes 0x08 - 3rd Move 2 Bytes 0x0A - 4th Move 2 Bytes 0x0C - Level 0x0D - 0x00 0x0E - HP EVs 0x0F - Atk. EVs 0x10 - Def. EVs 0x11 - Init. EVs 0x12 - SP.Atk. EVs 0x13 - SP.Def. EVs 0x14 - ID 2 Bytes 0x16 - SID 2 Bytes 0x18 - IVs 4 Bytes 0x1C - PID 4 Bytes 0x20 - Nickname up to 9 Bytes + string terminator 0xFF 0x2A - 0x00 0x2B - 0xFF For the trainer class indexes you can refer to here: RS, FRLG, Emerald For the win/lose/intro quotes you can refer to here: RSEFRLG - Dictionary (Easy Chat) e-Reader Berries Spoiler e-Reader Berry Structure (1328 Bytes) Save Offset RS 0x2E0 (Section 4) RAM Offsets RS (EU/US) 0x02028894 RS (JP) 0x020285F4 --------------------------- 0x000 - 0x006 berry name + 0xFF string terminator 0x007 firmness 0x008 - 0x009 size (in mm) 0x00A max yield 0x00B min yield 0x00C - 0x00F berry tag line 1 RAM offset 0x02028D50 (US) / 0x02028AB0 (JP) 0x010 - 0x013 berry tag line 2 RAM offset 0x02028D7D (US) / 0x02028ADD (JP) 0x014 growth time per stage (in hours) 0x015 - 0x019 flavor 0x01A smoothness 0x01B 0 0x01C - 0x49B berry sprite (4bpp) (48 x 48 px) 0x49C - 0x4BB palette (16x2 Bytes / 5 bits per color) 0x4BC - 0x4E8 berry tag line 1 0x4E9 - 0x515 berry tag line 2 0x516 - 0x519 effect in bag 0x520 - 0x527 filled with 0 0x528 - 0x529 effect as held item 0x52A - 0x52B filled with 0 0x52C - 0x52F checksum Effects as held item 0x00 no effect 0x04 cures poison 0x05 cures burn 0x06 cures freeze 0x08 cures confusion 0x17 restores a lowered stat 0x1C cures infatuation Checksum unsigned long berryChecksum(char* berry) { int x; unsigned long checksum = 0; for(x = 0; x < 0x52C; x++) if(x < 0xC || x >= 0x14) checksum += (berry[x] & 0xFF); return checksum; } 1 Link to comment Share on other sites More sharing options...
theSLAYER Posted May 27, 2018 Share Posted May 27, 2018 @YoshiMoshi here's a gif for the receiving process: 10ANNIV Spoiler AURA Mew (sent to French Ruby): Spoiler Shiny Zigzagoon Spoiler 1 Link to comment Share on other sites More sharing options...
Halfshadow Posted June 28, 2018 Share Posted June 28, 2018 Does Emerald support e-berries? Link to comment Share on other sites More sharing options...
PMArkive Posted January 22, 2019 Share Posted January 22, 2019 I was curious how the US Colosseum Bonus disc knows whether the Wishmaker Jirachi has been received on a save, but it doesn't appear to be through any flags that PKHeX can diff (along with much of the save's data moved around). Here are the save files if anyone else wants to look at what changes Sapphire Before Jirachi.sav Sapphire Post Jirachi.sav Link to comment Share on other sites More sharing options...
BlackShark Posted January 22, 2019 Share Posted January 22, 2019 1 hour ago, PMArkive said: I was curious how the US Colosseum Bonus disc knows whether the Wishmaker Jirachi has been received on a save, but it doesn't appear to be through any flags that PKHeX can diff (along with much of the save's data moved around). Here are the save files if anyone else wants to look at what changes Save block 4 offset 0x2B1 is set to 1 when Wishmaker Jirachi was received. That's at 0x82B1 in your Post Jirachi save file. Link to comment Share on other sites More sharing options...
Guest Posted January 22, 2019 Share Posted January 22, 2019 (edited) - Edited December 22, 2019 by Guest Link to comment Share on other sites More sharing options...
PMArkive Posted January 23, 2019 Share Posted January 23, 2019 1 hour ago, BlackShark said: Save block 4 offset 0x2B1 is set to 1 when Wishmaker Jirachi was received. That's at 0x82B1 in your Post Jirachi save file. Aye, you're right. I don't know if you found this in the Ruby/Sapphire disassembly, but I didn't think to look there until after your post... I tested with this code in PKHeX (well, a worse version of the code at first): public bool WishmakerJirachiGiven { get => GetFlag(BlockOfs[4] + 0x2B1, 0); set => SetFlag(BlockOfs[4] + 0x2B1, 0, value); } @Kaphotics would you be interested in adding the flag into PKHeX somewhere? 3 Link to comment Share on other sites More sharing options...
Kaphotics Posted January 23, 2019 Share Posted January 23, 2019 RS: https://github.com/pret/pokeruby/blob/51ecf10029f84dd5423cd59582d01eaee9140c0e/include/global.h#L727 E: https://github.com/pret/pokeemerald/blob/master/include/global.h#L885 FRLG: https://github.com/pret/pokefirered/blob/8367b0015fbf99070cc5a5244d8213420419d2c8/include/global.h#L745 seems like it was just an unused byte that was reused by the disc; since it only can be delivered to RS, I added some safeguards: https://github.com/kwsch/PKHeX/commit/7bb3f14e1f5eb3a49330a3b23207523a7783010e no gui support atm; can flip it pretty easily with linqpad: var path = @"savefile full path goes here"; var data = File.ReadAllBytes(path); var sav = new SAV3(data, PKHeX.Core.GameVersion.RS); sav.HasReceivedWishmkrJirachi = false; File.WriteAllBytes(path, sav.Write(false, false)); 2 Link to comment Share on other sites More sharing options...
Sabresite Posted January 24, 2019 Share Posted January 24, 2019 Most likely other events had flags too. I think I remember Bulbapedia saying something about 48 celebi total being able to be transferred? How is that determined? Link to comment Share on other sites More sharing options...
Guest Posted January 24, 2019 Share Posted January 24, 2019 (edited) - Edited December 22, 2019 by Guest Link to comment Share on other sites More sharing options...
Guest Posted January 24, 2019 Share Posted January 24, 2019 (edited) @Purin is right. Distribution Count must have been stored on the Colosseum save file. The flag is indeed checked and set only by the Wishmaker Jirachi Multi Boot ROM, which does have FRLG support, it’s just locked by the function that calls the subroutine to check the GameCode. This check was exclusively added for the Wishmaker Multi Boot ROM, I think because of the Berry Program Update. The same Jirachi flag however is also used by the known earlier version of the software (client.2003_1112.bin/Meteor Jirachi) which uses the same Jirachi flag, there it only checks the language version and that’s why it always works with RSFRLG by default. Interesting to note: The Meteor Jirachi Multi Boot ROM doesn’t have any function of the SIIRTC library so this was added for Wishmaker. Also the Setup for the Origin Game is missing in the Meteor Jirachi version what I think could be leftover from the Alternate Negaiboshi Jirachi (distributed via GCN development system) where it was not needed as it was determined by the GameCode of the inserted cartridge, same as the OT Gender is missing which was based on the Trainer's OTG. I think that the Jirachi flag could be originating from it, because it looks the alternative Negaiboshi Jirachi was self-service and that's possibly why they added that restriction. However without an original save file we are unable to confirm it. Also I have read that some PCNY events were limited, not sure if it was about the GBC Events or GBA Events as it was a blog entry about PCNY Events in general. What’s interesting... client.bin and client.2003_1112.bin have Emerald support (which must have been in early phase) and there even is a check whether the cartridge inserted is inserted, although not working by default, but with some little tweaks these Multi Boot ROMs also work with Emerald. Why it works even Emerald was not finished yet is simple to explain because the Multi Boot ROM support as far as preparation of Offets goes for FRLG and E is identical. In these games close to the ROM header (starting at Offset 0x08000128) there is some information stored which is used by the Multi Boot ROMs to determine specific save file offsets universally. Obviously when they made the newer GBA Pokémon Games they added this for a better Multi Boot support, they didn't had to add much new code for new games and it also keeps the Multi Boot ROMs as light as possible. Edited January 31, 2019 by ajxpk Link to comment Share on other sites More sharing options...
UndeadxReality Posted April 10, 2020 Share Posted April 10, 2020 I'm sorry to bump this thread after over a year and a few months but I was looking through the thread and noticed the scripts pertaining egg events didn't seem to have a line dedicated to OT, Trainer ID, and Secret ID. In theory wouldn't that be something we could script in to change or would that be impossible? Link to comment Share on other sites More sharing options...
Sabresite Posted April 11, 2020 Share Posted April 11, 2020 Which egg scripts? Wondercard? If so that is all done when generated in-game Link to comment Share on other sites More sharing options...
UndeadxReality Posted April 11, 2020 Share Posted April 11, 2020 Just the mystery.gift.tool scripts you can get from xse export. Link to comment Share on other sites More sharing options...
Sabresite Posted April 12, 2020 Share Posted April 12, 2020 I think you can do quite a bit but there is limited space because it's a fixed size iirc. If it's an egg then it doesn't matter once it hatches. Link to comment Share on other sites More sharing options...
BlackShark Posted May 28, 2020 Share Posted May 28, 2020 Hasn't been documented anywhere yet I think: FRLG/E e-Berry Structure FRLG: Section 4 - 0x026C E: Section 4 - 0x0378 0x00 - 0x06 berry name + 0xFF string terminator 0x07 firmness 0x08 - 0x09 size (in mm) 0x0A max yield 0x0B min yield 0x0C - 0x0F berry tag line 1 ROM offset 0x10 - 0x13 berry tag line 2 ROM offset 0x14 growth time per stage (in hours) 0x15 - 0x19 flavor 0x1A smoothness 0x1B 0 0x1C - 0x1F effect in bag 0x24 - 0x27 unknown pointer 0x28 - 0x2B unknown pointer 0x2D - 0x2E unknown 0x2E - 0x2F effect as held item 0x30 - 0x33 checksum The size is 52 bytes. Checksum is calculated the same way as in RS, except that it does not skip 0xC - 0x14 for the sum. 3 1 Link to comment Share on other sites More sharing options...
Guest Posted May 29, 2020 Share Posted May 29, 2020 Good to have it confirmed now. I have added it to the first post. Link to comment Share on other sites More sharing options...
Recommended Posts