Kaphotics

The goal of the 'database' is to have the fastest load & search speeds possible. Sorting the database within the GUI isn't really intended; it's more for searching through your dumped pkm & sav backup contents. For speed, the program loads data on parallel threads, so ordering isn't preserved. If you add the below line of code: RawDB.Sort((x, y) => x.Species.CompareTo(y.Species)); ... right above this line (link) and recompile, the program will sort the database once it's done loading all the files. For a database of 111,000 -- mine, the Species Sort took 137ms; I have a 4x4GHz processor, others might not have comparable specs. I prefer to keep the original sorted order, as the bak savefiles are loosely grouped together in slot order. Species order is meh, others might prefer ordering by format, or a more complex sort (which would take a non-negligible amount of time for larger databases). For a more complex sort: RawDB = RawDB.OrderBy(z => z.Format).ThenBy(z => z.Species).ThenBy(z => z.Gender).ToList(); That will sort by format, then by... but takes a bit more RAM/cpu to process the sorting.

You can manage your exported files however you want.

PKHeX can read encrypted pbr saves. No need to decrypt with other tools after you extract it from PBR.

You lend a pkm to an old man

Will be possible in the next release for acquired secret base data. Import/Export {location - trainer name.sb6} data

That might be why I shifted by 1 for my testing savefile back 3 years ago; you might have to debug for that one. XD saves aren't the same as mainline saves, they're kinda dynamically saved.

https://github.com/kwsch/PKHeX/blame/63c705061de58fd5bc44cc04c65d51f7c05ef74f/PKHeX.Core/Saves/SAV3XD.cs#L280 and Line 298, added via https://github.com/kwsch/PKHeX/commit/78cb0d87fa8f65fafa2b91c9b831f400a105010e Should be resolved in the latest commit: https://github.com/kwsch/PKHeX/commit/e81e5f31daadd481c24d404072ace956e3720df1 ty

You'd have to debug the program to see why it's acting incorrectly; I don't really care much for the C/XD minor features.

Try moving the exe to a different location, if that doesn't allow things, run as administrator. The error message you posted is not from dragging a Pokemon, it's from dragging a wonder card in the mystery gift editor.

You need to load save files instead of save states. .sa# (save state) is not a .sav (save file).

Thanks, will be handled more cleanly in future releases: https://github.com/kwsch/PKHeX/blob/a30a00317fc2602606c771403cc93c28079474e5/PKHeX.Core/Saves/Substructures/Gen6/MysteryBlock6.cs#L58-L76

Giving yourself the Mega Ring doesn't unlock the functionality. Use the trainer editor. Out-of-battle Mega formes aren't supported; whatever behavior it has is what you get.

The underlying question is: why do you even want to do illegal transfers? Anything is possible if you bend the rules. If you really want gen2-->gen3, you're creating invalid data since the source cannot be transferred legally.

Gen2 cannot transfer to Gen3. PKHeX emulates all transfer methods that the games allow. If you want backwards or disallowed conversion methods, you'd just be faking the data.

Update your Windows. Windows 7 (service pack 1) can install net 4.6 https://www.microsoft.com/en-us/download/details.aspx?id=48130

send img pls

Restore backups and only randomize/bump levels once. If you keep repeating the action, it'll compound their levels.

Ask GameFreak.

Close the program to save / flush all changes.

Download some premade files. The batch editor edits, it does not create.

Find the language ID you need to set (view a pkm with the selected language, then check what the Batch Editor says the Language value currently is). .Language=(insert value here) .IsNicknamed=false

If it doesn't line up with the RNG algorithms (PKHeX nor RNG Reporter), it's likely something wrong on the user's end (emulation, active cheats, idk).

Might be worth checking if this is an antishiny spread

PKHeX marks nicknamed events as Fishy. You can access the full report by holding control when clicking. It's possible to nickname anything, so long as you have the same trainer details (can be done via RNG abuse).

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.