Metropolis

Has anyone investigated what determines the dolls in Lorelei’s house on Four Island in Fire Red Leaf Green? It appears to be linked to hall of fame data, but I haven’t come across a map of win count to dolls. Does it stop at 200 like the braggart trainer card stickers?

Apologies to the moderators if bumping a two year thread violates any rules, but I’m interested in any work being done in this area and may be able to contribute. Thanks suloku for this excellent research. Could anyone who has edited N64 save files provide some additional info on: Endianness of bytes (big/little) Other checksums across the data sections that would need to be updated when the regions detailed above are modified. Any other relevant research or implementations of dumping or editing the registered Pokemon (or other Pokemon stadium save data) including different formats and lengths of save files. It would cool to see a fully fledged Pokemon Stadium 2 editor, and this provides a great starting point for any developers. Thanks.

I'm working on a new version with the same UI as the legacy version that was more popular, which will work on any Java without having to compile against different versions of Java and OS.

Interesting I'll take a look, yeh.

I've updated this online tool to support Pokemon Sun and Moon PK7 files. Feedback appreciated as always, consider this untested!

No more or less than distributing the original distro ROM? Since the details concerning the algorithm will be documented and confirmed, along with bulbapedia etc updated then custom distro ROMs can be easily weeded out by comparison. If you would rather I refrain from releasing details that is OK, whatever is in the best interests of the community without heavily devaluing a collectable.

I own a 10ANNIV distro ROM, which I would prefer to keep out of the public domain for reasons of devaluing it. If anyone can point me in the direction of a decompiler, I would be happy to share the sections of the source code that generate the Pokemon distributed, including its trash bytes. Alternatively, removing the user interface code from the ROM then sharing that modified ROM would be acceptable. I have the development knowledge to make sense of decompiler tools and am interested in helping to prevent and identify fake distributions. Determining the generation algorithm and making it public is in the interests of everyone here - the physical device retains value for the novelty of connecting to physical cartridges without external tools, whilst everyone has access to the 10ANNIV pokemon (and others sharing the algorithm) through synthetic means. Please could anyone share the details of what they would do if they had access to the cart and I'll follow those steps, release the findings, which will be verifiable by the matching up with known legit 10ANNIV Pokemon. Please respect my decision not to leak the ROM, it's because it is a highly collectable item, I'm not enjoying having to be restrictive about it.

Excellent work and glad you found the editor helpful. Thanks for sharing your findings with the community

I think this is just whether the four bytes are represented as a decimal or hexadecimal number, the PID isn't changed just by opening and saving a Pokemon. Whne converting Gen 2 -> 3, the PID is computed using the attack IV (for gender), unown letter and shiny status of the gen 2 Pokemon, incrementing the LSB to hit a neutral nature whilst respecting the gender, unown letter, hidden power etc. In 99% of cases this is accurate, and the tool itself is just for fun anyhow, obviously all gen 2 -> 3 conversions are hacks.

Glad you got it working :-)

If you're using a 32-bit OS, you'll need the 32-bit download instead. It should work once Java is updated on your computer. Other than that I don't know, like I've said before I regret using the SWT library in Java as it's tricky to get it working on everyone's machine without matching the right library.

Only data files for an individual Pokemon are supported, not entire saves (yet).

The source code is available for anyone to adapt as required. I recommend using PKHex instead.

I haven't disassembled code before, but have the skills to learn. It's something I might look into now and again, there's some tutorials online on how to get started that look good. You're right yes, some people may care about a purely untouched Pokemon. Personally I don't, I'm only interested in data preserved by trading (IVs, PID etc) but that's just my bias, I'm all for understanding more about how the entire data structure is generated. My instinct is that the trash bytes are probably just whatever was already there and may even be constructible to any values at all by nicknaming the Pokemon in the slot before. I'll have an experiment with that and see if I can get some special values there. You're right that disassembling is critical to understanding the OT gender, which would also solve the trash byte mystery anyhow.

It's good practice to tolerate out of bound values or auto-correct them rather than throwing a stack trace.

Incidentally, a post by Kaphotics describes an algorithm for deducing the PID: Here we have PID=0xD3C450DF Flipped: 0x50DFD3C4 To decimal: 1356846020 IVs are 7/25/28/3/17/2 Anyone know what to do next to get the seed?

Before trading to Colosseum, a freshly generated 10Anniv Lugia had: (do & 0xff to get them in the usual 0 to 255 range) Nickname: [-58, -49, -63, -61, -69, -1, 1, 52, 1, 49] (-1 is the terminator after LUGIA) TrainerName: [-94, -95, -69, -56, -56, -61, -48] (which is 10ANNIV the full length, so no trash bytes here!) Caught Location: 255 Caught Game: 2 (Ruby even though it's transferred to a FireRed cart) The full profile of the Pokemon: Pokemon3 [attacks=Attacks3 [currentPP1=20, currentPP2=5, currentPP3=5, currentPP4=20, moveIndex1=105, moveIndex2=56, moveIndex3=240, moveIndex4=129, ppUps1=0, ppUps2=0, ppUps3=0, ppUps4=0], caught=Caught3 [byte18=2, caughtGame=2, caughtLevel=70, caughtLocation=255, caughtTrainerFemale=true, language=2, pokeball=4, secretID=0, trainerID=6227, trainerName=10ANNIV], core=Core3 [attackEV=0, beauty=0, cool=0, cute=0, defenseEV=0, egg=false, experience=428750, feel=0, heldItem=0, hpEV=0, nickname=LUGIA, smart=0, specialAttackEV=0, specialDefenseEV=0, species=249, speedEV=0, tough=0], genetics=Genetics3 [alternateAbility=false, attackIV=25, defenseIV=28, fatefulEncounter=false, hpIV=7, mark1=false, mark2=false, mark3=false, mark4=false, personalityValue=3552858335, pokerusDuration=0, pokerusStrain=0, specialAttackIV=17, specialDefenseIV=2, speedIV=3, friendship=0], ribbons=Ribbons3 [beautyRank=0, coolRank=0, cuteRank=0, ribbonArtist=false, ribbonCountry=false, ribbonEffort=false, ribbonLand=false, ribbonLeague=false, ribbonMarine=false, ribbonMtBattle=false, ribbonPurified=false, ribbonSky=false, ribbonTower100=false, ribbonTower50=false, ribbonWorld=false, smartRank=0, toughRank=0]] I have no idea what is significant about these trash bytes or if they are just the bytes that were there before it starting writing to that part of the memory. After trading to Colosseum and back the nickname bytes: Nickname: [-58, -49, -63, -61, -69, -1, 0, 0, 0, 0] The full profile of the Pokemon: Pokemon3 [attacks=Attacks3 [currentPP1=20, currentPP2=5, currentPP3=5, currentPP4=20, moveIndex1=105, moveIndex2=56, moveIndex3=240, moveIndex4=129, ppUps1=0, ppUps2=0, ppUps3=0, ppUps4=0], caught=Caught3 [byte18=2, caughtGame=2, caughtLevel=70, caughtLocation=255, caughtTrainerFemale=true, language=2, pokeball=4, secretID=0, trainerID=6227, trainerName=10ANNIV], core=Core3 [attackEV=0, beauty=0, cool=0, cute=0, defenseEV=0, egg=false, experience=428750, feel=0, heldItem=0, hpEV=0, nickname=LUGIA, smart=0, specialAttackEV=0, specialDefenseEV=0, species=249, speedEV=0, tough=0], genetics=Genetics3 [alternateAbility=false, attackIV=25, defenseIV=28, fatefulEncounter=false, hpIV=7, mark1=false, mark2=false, mark3=false, mark4=false, personalityValue=3552858335, pokerusDuration=0, pokerusStrain=0, specialAttackIV=17, specialDefenseIV=2, speedIV=3, friendship=70], ribbons=Ribbons3 [beautyRank=0, coolRank=0, cuteRank=0, ribbonArtist=false, ribbonCountry=false, ribbonEffort=false, ribbonLand=false, ribbonLeague=false, ribbonMarine=false, ribbonMtBattle=false, ribbonPurified=false, ribbonSky=false, ribbonTower100=false, ribbonTower50=false, ribbonWorld=false, smartRank=0, toughRank=0]] So there you have it: trading to and from Colosseum nulls the trash bytes after the terminator, hence trash bytes are of no relevance to a Pokemon's legality whatsoever - not even renaming them is required!

Shininess is one reason, custom nickname is another reason. Personally I enjoy the challenge of making the impossible possible lol. Something else, perhaps less unusual to be considered is how Colosseum/XD handles these trash bytes. We know from the save file discussion threads that the internal data structure is quite different in those games. Given Colosseum and are on a different console, it wouldn't surprise me at all for them to have a different character set and to handle the bytes separately. Tonight I'll generate a 10ANNIV Pokemon from distro cart, record its trash bytes directly from the save, then transfer to Colosseum and back, record its trash bytes again, then transfer to a 10ANNIV/6227/0 GBA save, rename and rename back then record the trash bytes. I'm concerned with legality not what is legit, but for those who are, I think if post-Colosseum trading is something to consider. Anyway, I'll post the bytes I get and you can make your own minds up about what is legit.

How can you 'guarantee' that, asking the people? As long as it is possible to renickname, it is *possible*, hence they cannot be considered illegal by any legality checker. Whether anyone has a reason to, or the time to go through a convoluted procedure is irrelevant. Shiny Manaphy are legal for the same reasons - highly unlikely someone has hatched the egg on a different game to bypass the shiny check, but possible hence legal.

I own a 10ANNIV distro cart and can investigate the seeding and trash byte routines, however it would devalue an otherwise unique item. There is nothing otherwise significant about these events, compared to say Wish Chansey or Jirachi. I expect the value of these carts to increase further in the light of the Pokemon Go revival, gold star Pokemon cards have near tripled in value since. What is worthy of research (without distro cart) is whether the 10ANNIV/06227/0 combination is rollable on a normal Ruby/Sapphire/Emerald RNG. If 06227/0 is rollable as a trainer ID/secret ID combination, then a new game with that Trainer ID, Secret ID and player name could be created, then it would be easy to trade them over and re-nickname. As long as such a trainer ID/secret ID is possible, then it is also possible for the Pokemon to be renicknamed, hence the trash bytes would no indicator of legitimacy. If this ID combination is never rolled by the RNG, then even if a hacked save allows renicknaming, there would be no 'normal' way to renickname these events. I think it's highly likely that such an RNG exploit is possible and hence trash bytes don't matter for any of the Gen 3 events. As an example - take Shiny Manaphy in Gen 4, though the event was engineered to roll a PID that would prevent shininess, players found a trick to hatch the egg on a different save with appropriately rolled trainer ID and secret ID, resulting in shiny Manaphy. I believe that 42225 is the first frame that will roll a trainer ID of 6227 and a secret ID of 0, where the seed is 0 (which it always is on Emerald). Will test the trading and renaming part using a genuine 10ANNIV event from distro cart and an Emerald save hacked to have 10NNIV/6227/0 as the player name/ID. The 'missing piece to the chain' of a totally legitimate trade-and-rename of a 10Anniv Pokemon would be for someone to abuse the RNG to create a save with that player Name, trainer ID and secret ID, which I believe is possible. TLDR: Trash bytes are irrelevant to legitimacy.

I don't think you'd need two to verify - if it's not shareable the first device would not be able to start sending it. After that other devices can listen for the distribution but if not trade able you wouldn't get that far.

Neither - it injects exactly the wonder card data from the source save. If that's valid, so is the wonder card on the destination save. If invalid, the destination save will then contain an invalid card. At no point is any new wonder card created in the sense of the codes and Japanese tool.

See the attachment here for FRLG Aurora

I can confirm that a German wonder card can be injected into an English save, so language compatibility isn't a restriction if you're only interested in the effect after discarding the wonder card. Auroraticket in FRLG and Emerald are known, Eon ticket from eCard is available, leaving only MysticTicket to account for. Does anyone have a FRLG and Emerald save game with an undiscarded MysticTicket wonder card? From that the tools are in place to get all 'legit' tickets, since Old Sea Map was never distributed anyhow.

Interesting collection, great work. Could I make a suggestion? It has recently been discovered that due to generation 1's RNG, certain combinations of IVs are illegal, notably perfect spreads for almost all Pokemon. It would be great if in anticipation of Sun/Moon any illegal spreads could be weeded out. Of course on the real cartridges, connection to Gen 2 is possible, opening up almost all spreads due to the new breeding mechanics, but for Gen 1 -> Sun/Moon this would be an issue. The rules for legit spreads actually turn out rather complex, if you look through some of the research that's been done around the RNG you'll see what I mean. The rules end up depending on the encounter rate of the areas where that Pokemon could be caught. It's doable on a case by case basis, hard to implement with absolute confidence.