[GEN 3] Mystery Event/Gift Research

[Gridelin]

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.

[theSLAYER]

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)

[YoshiMoshi]

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

[Deoxyz]

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.

[YoshiMoshi]

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!

[theSLAYER]

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)

[Sabresite]

Even though Hadou and Aura are the same name, the distribution software was different. Lots of reasons for why that is.

[Guest]

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

[BlackShark]

@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;
}

 

 

[theSLAYER]

@YoshiMoshi here's a gif for the receiving process:

10ANNIV

Spoiler

AURA Mew (sent to French Ruby):

Spoiler

Shiny Zigzagoon

Spoiler

 

[Halfshadow]

Does Emerald support e-berries?

[PMArkive]

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

[BlackShark]

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.

[Guest]

-

Edited December 22, 2019 by Guest

[PMArkive]

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?

[Kaphotics]

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));

 

[Sabresite]

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?

[Guest]

-

Edited December 22, 2019 by Guest

[Guest]

@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

[UndeadxReality]

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? 

[Sabresite]

Which egg scripts? Wondercard? If so that is all done when generated in-game

[UndeadxReality]

Just the mystery.gift.tool scripts you can get from xse export. 

[Sabresite]

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.

[BlackShark]

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.

[Guest]

Good to have it confirmed now. I have added it to the first post.