Leaderboard

PKHeX is a save editor, it is not a "research team". New features can only be added once they are fully fleshed out by community research. If you want to edit the currently un-editable, you have to figure it out first before it can be translated to code. There's already a secret base editor for ORAS, but it does not let you visualize your decorations. Go in game to do that. Friend Safari changing is un-researched. You can already inject whatever PKM data you want, and can use someone else's save file with the Safari data if you really must see the species in game. === As for current goals: * Rework savedata property fetching to mimic how the games manage things. Recent games store chunks of data, and each chunk serves a narrow purpose. Splitting savedata r/w into chunk r/w will focus the code and reduce overall complexity, resulting in easier addition of features/code reuse. * Rework move legality checks for faster performance. Currently all legal moves are fetched, then the current moves are checked if they are within that list. It's quicker to check if a current move is learnable, rather than grabbing everything (memory allocation heavy). With every added legality check and new game data added (essentially yearly), legality checking gets slowly slower. Need to optimize things when appropriate to keep legality checking speed blazing fast so it can be done on the fly for many pkm's. * Rework the editing GUI of as many editors as possible to move business logic away from GUI code, and abstracting the editing process to not require a GUI to make edits. This results in easier to maintain/extendable editors, as well as more code reuse. * Migrate the codebase to .NET Core 3. There's many performance improvements and easier cross platform support. Release deployment would be adversely affected, as the .NET libs would need to be bundled with the executable. As you can see, this is mainly architecture & refactoring work, not stuff the user notices. However, the program is constantly growing so it's best to eliminate technical debt when possible. Most core editing features are already provided. For planning: * When more SW/SH info becomes available, I can start formulating how I think PKHeX could support editing the savedata. LGPE changed box storage to be a list of PKM data, rather than an array. No empty slots in the middle. This required special handling and code to fix the users edits when they save the file, rather than force them to obey the List behavior. * SW/SH will introduce new PKM, and will introduce new box sprites for every PKM. This will have big implications for GUI layout, as the sprites are bigger than they were on the 3DS. * Data for new games has to be ripped; documenting things manually is error prone and extremely time consuming. I've created pkNX to help dump data, but who knows how much will carry over to the new games. Is it worthwhile to document more LGPE/previous content and create code, in hopes that SW/SH will reuse that structure? I've always wanted to get script editing working; they're been using a new script engine since XY. Again, none of this is really related to savedata structure research. I don't really care about the minor features the games offer. PKHeX has always been a solo project with occasional contributors; as a result of this, maintenance and cleaning is my main focus, and minor feature research falls on the community.

You can use the following tool by suloku to unlock the third Pokemon in a Friend Safari without waiting for the person to go online. Editing which Pokemon will be available in the safari is not possible with save editing. Even though the relevant data is stored in the save file, it gets re-synchronized with you friend list each time you start your game.