Kaphotics

Fixed & Fixed Fixed Download the latest as of a few minutes ago

Yuzu does not support wireless/online communications. You can hack your switch (assuming it is an older model), then edit your save file from your legitimate game.

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.

pkNX has been set up as a class library for easy reuse in other projects. Inside the codebase is re-implementation of various game data structures and file locations. Structures Game File Locations Note: these urls are from when this reply is posted. For the most up-to-date reference, please browse for the files using the current commits. pkNX also includes an example of flatbuffer file conversion using a flatbuffer schema (.fbs), from *.bin -> *.json, and *.json -> bin. Use the provided fbs and bat files, which use the flatc.exe to convert the data. Keep them in the same folder as the stuff you're converting

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

I updated the program in my previous message; be sure you are using the latest commit version. The romfs should have 27,818 Files, 1,336 Folders The exefs should have 6 Files, 0 Folders Can't really tell more without the 'details'.

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!

Bad folder. The folder has to have an unpacked romfs & exefs with no extra files inside either of those two folders. I've updated the logic so that it no longer throws an exception, and instead returns the intended error message. https://github.com/kwsch/pkNX/commit/ec23818454962e1d95a51f43c29893e23dd37751

Edited ROMs can only be played on exploited consoles. Please do not ask (nor private message me) how to obtain/dump/decrypt/unpack/repack ROMs as that is unrelated to the functionality of this program. Download Link At Bottom of Post pkNX is a ROM editor for the Nintendo Switch Pokémon games with tools to edit various game data. All editors displayed are fully functional. Simply feed it a folder (drag/drop or by File->Open) which contains the game romfs & exefs extracted content folders. Edited files will be saved to a patch folder (named after the game's title ID), and will preferentially load edited files before defaulting back to the unmodified files in the romfs/exefs folders. Edited files are only saved when the program closes, and edits in individual windows can be discarded by hitting Close (X) rather than Save. Randomizers available: Trainer Battles (Pokemon / Items / Moves / Difficulty / Classes) Wild Encounters (Species, Level) Personal Data (Pokemon Types / Stats / TM Learnset) Move Learnset (Level Up) Evolutions etc Download the latest version here (click on latest run at the top, then click Artifacts - published, and download the folder) Source code is available on my GitHub.

Yuck, the starters have different EXP groups. Edit: should be fixed now: https://github.com/kwsch/PKHeX/commit/76a2e4f527689d7d6ab58f5567a22727f9ed1a82

The changelog explicitly states that Rare Spawns and Mystery Gifts are not recognized yet.

It's not documented, and won't be available to edit until someone figures out where & how it is stored in the save file.

Done https://github.com/kwsch/PKHeX/commit/3e711acd05973de2ceb7adab00bb9646c846cdd6 Thanks for reporting!

If it's not specified, then it's random.

Fixed, re-download

Fixed, re-download the latest commit

Read the source code that I provided. It tells you what offsets mean what.

Bad ROM dump.

Download the latest version. The one you have pictured there does not have Gen7 support at all.

Correct CP is only used for display purposes, so the '10k cap' doesn't affect anything in battle/etc.

The calculated CP can't go above 10,000 in-game; PKHeX's calculated CP didn't recognize this -- now fixed. https://github.com/kwsch/PKHeX/commit/65febae12548b9457ba4316f912c47fc6231f0b7 Game code (disassembly) for reference:

PKHeX is programmed in c#; the games are not. There are certain calculations that are done using floating point which end up with different results (between the two programming languages): Until a workaround is found, there may be some inaccuracy in the calculations (+/- 1 or ~0.0001)

Thanks, fixed: https://github.com/kwsch/PKHeX/commit/1c0b2488ef323b4cca00fd7562dfe7c8d971f1e7

You're probably doing something wrong when you're restoring the save data. If something was (simply) wrong with PKHeX, there'd be a flood of reports.