Kaphotics

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.

Thanks, added in latest commit: https://github.com/kwsch/PKHeX/commit/827eb94f3c272e58d53dcb76a1d804dcf85258ab

Thanks, fixed in latest commit https://github.com/kwsch/PKHeX/commit/7f9328e8833e57eea9b50c8c6756d43fbfdd3a8c

Nope, nobody has bothered researching it.

Already reported: https://projectpokemon.org/home/forums/topic/48525-lgpe-research-encounters-bleeding-into-a-different-location/

Fixed, re-download.

Nope! http://noseclub.bluwiikoon.art/gscshinyeggs.shtml Keep in mind that they can be shiny if they were transferred before GSC VC were released, since they didn't originally use the same DV->Gender/Shiny determination as Gen2.

gp1ed is written in Visual Basic, PKHeX is written in c# Although they are both .NET languages, it's not wise to mix languages. I don't want to rewrite or maintain stuff that can be easily kept in a separate program. Mystery Gift file editors have always been separate tools; I think gp1 should be handled the same way. They're just templates!

Yes. Blatant hacks/simple derivations aren't worthwhile contributions

If PokeGen and PKHeX can't load the file, then your file is invalid. Upload the file or look at it in a hex editor to verify that the contents are actually a save file.

It opens fine in the latest release of the program.

Entire save is not copied; it stores boxes for numerous savefiles, since you can connect with up to 4 different saves.

The second screenshot describes the game's behavior if you hack in a shiny.

You have to have your console load CROs and exefs in order for the game to be in sync. One file determines what is shown, the other determines what is picked out.

Restore backups and randomize only once.

You'd have to dig through the game code and figure out how to disable that check, assuming the problem exists in that way. Game code modification is pretty much outside the scope of pk3DS; you'd have to use other tools like IDA. There's always a way to do things, but the amount of effort and wisdom required usually isn't worth it.

The game possibly disallows same species evolutions. Keep in mind that the game will clear mega forms when you reload your party.

Thanks, fixed in latest commit. https://github.com/kwsch/PKHeX/commit/0dc45c00ec0db94423c4c620f74f58db356445e5 New release will be available by Friday at the latest

Few threads below:

Uploading to Pokécheck is enabled. Anyways, PKHeX does not modify the trash bytes for you. It is up to you to set the correct trash bytes afterwards. Keep in mind that gen4/5 aren't connected to official servers anymore, so any trashbyte issues really aren't that big of a deal. PKHeX doesn't have a method to set suggested trash bytes, because there isn't thorough documentation/implementation for that yet. I don't really care about them so someone else would have to do that work.