Leaderboard

Full Documents Related to the Distribution, the full copy of Pokemon Power Volume 6 is attached to this post: In the Fall of 1998 Nintendo Power held a contest to “Win Mew for your Pokémon collection!” 151 winners of this contest would be given the chance to mail their cartridge into the Nintendo Power Headquarters and receive it back with a brand-new mew on their game save. Contest winners were notified by mail by 2/28/1999 that they had won the contest, making this the earliest known Mew distribution in the west. Recently while browsing reddit, I ran across a post from Th4tGuyUKn0 showcasing his Original Red cartridge that was one of the lucky recipients of this contest. After scrolling through the thread, Th4tGuyUKn0 stated that the battery on the game had not yet dried out; upon reading this I immediately messaged him explaining Project Pokémon and asked him if he would be interested in dumping his game save. Luckily, he was all for it! The only problem was he could not remember which of his five Pokémon cartridges he left the mew on, and did not want to risk draining the more than two decades old cartridge battery by checking. Th4tGuyUKn0 graciously decided to send me all of his cartridges so that I could backup the saves and hopefully find the mew. With the amazing research done by @suloku on these save files, we are confident that we have found the Mew in question. In the Pokemon Blue game save we discovered a Mew with the TID 51273 (the same Mew ID# printed on the back of the cartridge) and the OT ‘MARIO’. Suloku has concluded that this Mew is definitely legit. It shares the exact same DVs as the YOSHIBA Mew, matches Mew machine distributions data-wise, and has the same OT Nintendo character naming convention that several forum posts from 2000~ reference. While this does raise questions about what distribution the supposed ‘NINTEN’ Mews are a part of, this Nintendo Power Mew is most certainly legit. Suloku was also able to find the Mew in the red save file as a deleted Pokémon (moved or deleted pokémon can be found in box savedata if it was not overwritten by another pokémon being stored in the same slot). Attached is the the .pk1 of the 1998 Nintendo Power 'MARIO' Mew. Thanks very much again to Th4tGuyUKn0 for sending and trusting us with these cartridges and Suloku for all of the great research, none of this would have been possible without them. Happy holidays and enjoy! 151 - MEW - C23C.pk1 Pokemon Power vol 6.pdf

Iirc there was an ar code somewhere in this thread that allows you to reset every berry patch in the game in such a way that it acts like it's your first time visiting the route (for berries only, it doesn't affect any other events). Best of luck to you

As I was gonna reply before Kaphotics did (and I was gonna tag him anyway), I'm glad to see such a succinct and clear reply from him. In any case, this was my original response: and I previously said, I don't know, and I doubt such a Celebi exists. Maybe they (Nintendo/Game Freak or the event staff) decided to halfway through distribute it with SoulSilver as the origin game. Unlikely, but possible. Hence, I don't know, but I doubt it [it as in such a wonder card legitimately exists].

No, it just doesn't have a list of what gen4 games can receive a given gen4 card. I'm not putting that information together myself; the community hasn't felt it is necessary either.

Gen IV events had preset origin games. (their origin game is already set on the wonder card) Gen V onwards used 00 to represent follow receiving game, but some events had a preset origin game (Usually events tied to a players/champion Pokemon) edit: Examples I can think of https://projectpokemon.org/home/files/file/589-screenpeekazs-shiny-machamp/ https://projectpokemon.org/home/files/file/2862-na-internationals-2018-ryota-otsubos-krookodile/

It works now! Would've been nice to know that in the first place, I can't help but wonder if roms I've tried to get working in the past have failed because of this as well.. None of the information I've found on the internet has mentioned this whatsoever. Thank you so much ;w; Especially for the quick reply.

I like how the age question on the contest entry form has "18-24" oldest possible response. ri

Use LayeredFS with your CFW (would recommend Atmosphère). Once you're done making your edits, pkNX generates a folder named after the game's Title ID which can then be moved to your SD Card in the proper location, depending on your CFW. If we use Atmosphère as an example, you move the Title ID folder to sd:/atmosphere/titles/ 010003F003A34000 = Pokémon: Let's Go, Pikachu! 0100187003A36000 = Pokémon: Let's Go, Eevee!

Starting a topic related to reverse engineering the romfs, specific for the switch pkm titles. Reverse engineering ROM filesystem data for the Let's Go! Pikachu/Eevee games is easier than the previous games for the 3DS, as the games lack usage of NARC/GARC packed files in favor of having mostly unpacked contents. The romfs is obtained by decrypting the ROM and unpacking with tools such as hactool. The Nintendo Switch patching system uses delta patching and full-file replacement with a virtual romfs. The 3DS patching method only had a virtual romfs file used full file replacement. Smaller patches are now possible, with best results if most files aren't packed together/compressed. The Nintendo Switch uses LZ4 as its primary (de)compression method as it is insanely fast relative to other methods. A fair amount of content is kept between games; certain data structures are reused without change, as there's no need to reinvent the wheel. This is advantageous for reverse engineering, as we can compare known past game data to the current games. By comparing old and new, the updated data structures can be documented quickly and noted for changes. One of the common problems in game development is translating human readable data into concise blobs of data for the game to use. Programs like pk3DS, pkNX, and various parsers are created to visualize the binaries the game uses, but during the game design phase, serialization from words -> data is much more difficult. To alleviate this issue, it appears that GameFreak has employed FlatBuffers as a way to handle irregular data structures like Wild Encounter data, Pokémart data, and others. They likely serialize (with a custom parser) from an excel spreadsheet into json, then compile the json with a flatbuffer schema to get the compiled binary and source code to read the compiled data. Reversing FlatBuffers is much more difficult than concatenated structures due to vtables and other annoyances, but it is possible with enough dedication The NDS and 3DS games used .narc and .garc as their main way to package files; this is no longer the case for LGPE. All files are unpacked, although they still use .sarc, mini, and other various sdk containers to bundle together some files (e.g. GUI assets). To replace the blz/lz11 compressed files, they now use lz4 in addition to 'zipping' into a .gfpak archive. LGPE fortunately include filenames in the 12,000+ files that you'll get with unpacking the romfs. The game retrieves files starting with the root folder ("bin"), followed by the subfolder path (with "/" directory separators). A fair amount of indirect / non-hardcoding is present for loading game assets, which is accomplished by some data structures storing a 64bit hash [hashing a file's path starting with "bin" or only the filename]. This hash is computed via a 64-bit FNV hash one character at a time. The game keeps various hashtables (file magic "AHTB"), which stores the hash and the string that was hashed. This allows for easy retrieval of the value's index within an array (e.g. to set an event flag based off the name of the flag, rather than the absolute index). Feel free to discuss your findings about the game romfs here!

Wouldn't surprise me if they purposefully have 'force shiny' doing the same as pure rand, since no gifts should be forced shiny. I checked the setup method and saw it using the shiny type stuff, but the actual pkmcreate stuff is called from a function pointer (too hard to dig up for now). Will look at the SingleFile container edits not being saved... edit: fixed

done

Starting a topic related to reverse engineering game code, specific for the switch pkm titles. Reverse engineering code of Nintendo Switch titles is most commonly done with the Interactive Disassembler (IDA) and the Hex-Rays extension, which converts the assembly code to easier to understand c code. Using SwitchIDAProLoader, you can load the game .nso file which generates the .i64 database used for 'disassembling' the game code. With the disassembly in hand and a blind understanding of how the code is laid out, finding your bearings within the millions of instructions is hard. It is recommended to search for a sequence of values, such as the list of TM Moves (ordered TM01, TM02, TM03), then branch out from there. Keep in mind that the games were programmed by humans, but the compiler may optimize things into relative gibberish. Useful hotkeys: F5 with cursor placed on/within a function = go to function definition x = cross reference list for selected variable/function / = add new comment n = rename variable/function escape = go back (e.g. if you go to definition then press escape, this will pop you back out to where you were before peeking). Here's some hints: byte sequence (68 96 40 39 94 06 00 11 9F 02 08 6B). This will put you in the method that creates the pkm's PID, which is called every time a new Pokémon is generated (sub_71007399B0). Search "Immediate value" for '632' (Shiny Charm item ID). Filter by MOV instruction. The third result=sub_71002F6760 (which is the first that actually uses 632 immediately in a function call) is the wild catch combo shiny rate/IV determination method. Search "Immediate value" for '874' (new Silph Scope item ID). Filter results by MOV instruction again. This will get you the 'has inventory item' function (first=sub_71002BF180 and second result=sub_71002fe3c8). The latter result from above is the main wild spawn function sub_7100300B84 (gets the Height group xs/s/normal/l/xl) which is called by the above method, is also used by sub_710082D89C. This method is the 'exp boost' factor which gives bonuses based on throw type/etc. Feel free to discuss your findings about the game code here!

Finally, after taking pretty much forever, with the aid of @Saternoir, we are getting somewhere in regards to removing the background. I'm using this thread to detail the little progress we have done, so that we don't lose track of the methods. First of: SM - Garc A123 USUM - Garc A124 Containers format: Garc -> 0.bin (compressed LZ11) Mini format (BL) -> various ALYTs. The one of interest is 1.alyt. ALYT and Mini to be extracted and recompiled using Saternoir's fork of 3DSkit. At this point, using the garcs crash the system. It appears repacking the 1.alyt might be the cause. I've unpacked 0.bin, repacked it (without modifications), and compressed it, and the game works. However, the garc made by repacking the 1.alyt (without modifications) caused crashed.