Kaphotics
-
Posts
7828 -
Joined
-
Last visited
-
Days Won
449
Content Type
Profiles
Pokédex
Portal
Technical Documentation
Pages
Tutorials
Forums
Events
Downloads
Gallery
Blogs
Everything posted by Kaphotics
-
Does an unedited save file (from the emulator) have valid checksums, via the SAV tab? If PKHeX remembers your changes, and the emulator reversed it, then that's not an issue with PKHeX. The emulator has to import your edited save file, oftentimes it will ignore it / keep it cached internally with a RAM snapshot for faster resuming.
-
If reopening the edited save in PKHeX shows your changes, then data doesn't magically revert. I don't know how every single emulator works. If you're not importing the edited save, then it won't use the updated data.
-
Totally would help if you included your discord information.
-
Don't look for FRIENDS in the tiny rooms. If the ROM hack is glitched and gives no encounters for that room, then just play on an unmodified copy of the game to obtain them, as this hack has not been updated in 10+ years.
-
A-Save is a separate program you can download. Without seeing your save file (via upload), can't know for sure. Again, if multiple editors reject it, then it likely isn't a valid dump.
-
In the unmodified game, the forms you mentioned spawn in different rooms. Could it be you're not looking in the right map?
-
The Block Editor allows for changing tons of flags, but it is no replacement for regular gameplay progression.
-
Check if they are indeed valid backups of your save file, and of the standard format that isn't compressed in any way. Try checking other save editors like A-Save; if it doesn't work in multiple editors, then it's likely your save file being bad.
-
No. Nothing of the sort exists for prior games either.
-
why not just use a save file editor like PKHeX and limit yourself to only add/change what you feel is right?
- 1 reply
-
- 1
-
-
Have you progressed any bit within the game, like received your starter pokemon?
-
PKHeX does not change anything about the real time clock data that emulators append to the end of the save data. If your emulator does something funky when loading the save file like looking at the date modified, that's on them. Again, nothing is touched by PKHeX, it's an emulator issue.
-
PKHeX does not support ROM hacks. This ROM hack in particular has changed how the data is saved in the savedata.bin, so it's essentially an entirely separate game as the regular data structures cannot read the data the same way. They have a fork of PKHeX that adjusts the code to read their variant, but it is not supported or discussed here.
-
Nope; if it's a misassigment by HOME or by the user, PKHeX will flag it. You can fix it by putting them back in HOME and retrieving them. I'm not changing that priority. As previously mentioned, official glitches are still flagged by PKHeX. Invalid move PP, bottle caps, etc, still flagged.
-
They need to be handled by the OT (not the HT), since they're from your save file. PKHeX flags incorrect states; this could very well have been a bug with early versions of HOME and fixed. Same as the Gold Bottle Cap issue that GameFreak later fixed, it is better to flag the incorrect state and get the user to fix their error, as you need to consider that 99% of people who encounter this error in the present day are because they generated data incorrectly instead.
-
Incorrect format. Needs to be a 128KB save file, not 64 KB.
-
Can't know what is happening without knowing the trainer ID of the currently loaded save file, and the ID of the Pokemon. If the Pokemon details matches the save file, then it should be handled by the OT, otherwise, should be the HT. Hence the message. Sharing trainer IDs across different versions results in incorrect handler flags because the game does not check the trainer Version, and it's a sign that the Pokemon or save file is not legitimate.
-
Date modified on your save file is an hour before your original post, yet you have save states with more recent timestamps (today). Be sure you are exporting your edited save file from PKHeX (date modified changes), and that the emulator is told to look at the edited save file (depends on the emulator).
-
Verify that you're setting your changes to the spots you're intending, and that you're exporting your save file to the correct file location. PKHeX doesn't eat your changes and ignore them on export; data does not magically revert.
-
You haven't mentioned how you are playing your game, via emulator or on console. If emulator, find where the emulator stores its save files. If console, dump it the same way you dumped the ROM. Not all emulators behave the same and store consistently, and it's outside the scope of PKHeX. Once you find your save file and have it exported correctly, you can load it into the program.
-
PKHeX is a save file editor. You uploaded an nds file, which is a ROM. Open the sav instead.
-
Was reported and fixed earlier, use the dev build or wait for the next release (maybe end of this weekend)
-
"HaX" only unclamps some editors and allows disabling the recalculation of stats. If the emulator does not recognize changes, and your changes persist when reopening the save with the editor, then you didn't import your save back to the emulator correctly. Be sure to not be using save states when resuming your emulation session, as the emulator needs to read your saved data rather than continue from a previous snapshot.
-
Create Shiny Egg for Gen 4 Pokemon using Core.DLL
Kaphotics replied to evievi's topic in General Development
In generation 4, shininess is determined based on who hatches the pokemon. You're using two separate objects to fetch the trainer ID. The code you pasted does not compile on the latest PKHeX.Core dll, because `ShinyUtil.GetShinyPID` requires different typed arguments. public static uint GetShinyPID(in ushort tid, in ushort sid, in uint pid, in uint type) { var low = pid & 0xFFFF; return ((type ^ tid ^ sid ^ low) << 16) | low; } TrainerTID7 is a uint, not a ushort. When in doubt, look for how PKHeX itself uses the methods: As you can see, you need to provide the 16-bit trainer values. You're passing in a 0 for the old PID, so the shiny PID that comes out will be less "random" with the lowest 16 bits being 0.
