Kaphotics

Before unzipping, right click the zip and properties -> unblock.

done https://github.com/kwsch/PKHeX/commit/fc65a65fd95c890164bcddbe48550ec8b29c3672

GO transfer IVs are locked to a specific pattern; hacking the IVs arbitrarily usually won't align with the requirements. Speed is random, defense ivs must be equal, attack ivs must be equal, and every iv except speed must be odd.

Changing AVs requires recalculating CP. You can do this on the most recent commits by doing: .Stat_CP=$suggest

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 (log in as guest, zip is under Artifacts tab) Source code is available on my GitHub.

Thanks for reporting, just a few straggler cases that weren't caught https://github.com/kwsch/PKHeX/commit/3038c1eedb1a8f7851ae8c2c543391ec5079cc31

It's that way to prevent save files from having too few encounters/eggs vs stored when compared to total stored in boxes. There are program settings toggles inside the options menu to disable this...

If you feed it a encrypted pkm, it will decrypt it and provide you with values as you ask for them. Most of the shared logic is in PKX.cs, and SaveUtil.cs Basically the program reads the data, then various utility functions bend it into usable shape. Probably, but I'd advise against using multiple languages that you are unfamiliar with in the same project. If 'decrypt' means deserialize, then yes, you could use serialization with the pkm/sav by exporting it to json or whatnot. Sure. Here's an example using LINQPad with a reference to PKHeX.Core.dll: With LINQPad you can also 'Dump' which gives a ton of info about the object that is dumped: ... (cropped)

PKHeX doesn't do full deserialization of the pkm/sav files, it only gets/sets data on demand. PKM.cs is the base abstraction of the PK* format, with multiple different formats of storing the data across generations (ie PK1/PK2...PK7...). SaveFile.cs is the base abstraction of save files, with multiple different formats of storing the data across generations (ie SAV1/SAV2...SAV7...). PKHeX.Core.dll is the class library the GUI uses to power most of the pkm/sav data manipulation. If you add it as a reference to a (.NET language) project, you can use its api to automate your edits. PKHeX also offers plugin capability, where you can program your own toolkit and launch various operations.

Author's Webpage: http://www.geocities.jp/bt_vermeille/remodel/pokemon_bw/ | (B2W2) Japanese Program. .NET 2.0 Required. Edits the ROM, not narcs. Features: Species Editor Evolution Editor Encounter Slot Editor Move Editor Download *TRANSLATED* Pokemon ROM Changer: B2W2 - English ROMs (by Kaphotics) B2W2 - JP Translation (by Kaphotics and Andibad) BW Translation (by Andibad) For ROM Hacks: PRC for BBVW2 Complete 1.1 PRC for BBVW2 Vanilla 1.1 PRC for BBVW2 Complete 1.00 PRC for BBVW2 Vanilla 1.00 Bond697 has graciously provided decompiled code (via .NET Reflector). It's not the original code, but it compiles into the same program. Original prc_bw2 (B2W2) Original prc_bw (BW) --Source for prc_bw2 translation (English) --Source for prc_bw2's translation (JP)

Thanks, fixed in latest commit https://github.com/kwsch/PKHeX/commit/77a4691a58cc45f63c904eecf8a6d31a46231d4c

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

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

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 pk3DS is a ROM editor for 3DS games with tools from various contributors. 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. Randomizers available: Trainer Battles (Pokemon / Items / Moves / Abilities / Difficulty / Classes) Wild Encounters (Species, Level, Gen/Legend Specific, ORAS DexNav won't crash!) Personal Data (Pokemon Types / Stats / Abilities / TM Learnset) Move Randomizer (Type / Damage Category) Move Learnset (Level Up / Egg Move) Evolutions TM Moves Special Mart Inventory etc Download the latest version here (log in as guest, zip is under Artifacts tab) Source code is available on my GitHub.

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.

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)