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.