Jump to content

Kaphotics

Helpful Member
  • Posts

    7271
  • Joined

  • Last visited

  • Days Won

    362

Everything posted by Kaphotics

  1. Thanks, should be good now with the latest commit https://github.com/kwsch/PKHeX/commit/ed3699fbb45b71c723e443eb96b3df3f3cb42f0e
  2. @theSLAYER nice find Fixed! https://github.com/kwsch/PKHeX/commit/a3e7c4837e8b837236c1cff8db0f12d8d17b3d51
  3. That's fine, but be sure to put the species=Haunter ones in the Unreleased folder
  4. PKHeX uses simulated wondercards for these local trade events. The events gallery should instead change the faked data so that it's distributed as a Gengar instead (since there's no way to end up with Haunter after the trade is over). @Sabresite https://github.com/projectpokemon/EventsGallery/commit/f92d5a7a4828376af3f9d013501a513da636bb75
  5. Kaphotics

    bug in last update

    Refer to our event database, which lists that event as having its hidden ability. Pretty sure Serebii's site is wrong as bulbapedia also lists it as having its hidden ability.
  6. And then when you trade it back to Colo/XD, it will show "MONTE L". I don't think it's absolutely necessary to add edge case handling for this. Colo did not have a legality check of this caliber. Maybe I can do something about it... edit: done, should be Legal now https://github.com/kwsch/PKHeX/commit/93af3e61b7fc12f9d010c7071279107841505359
  7. Gen 3 (pk3) through Gen5 have a max OT Name length of 7
  8. You have an outdated build of RNG Reporter. Recent builds (and pokefinder) list that PIDIV frame as Slot 1, not Slot 2. https://gyazo.com/e58393c0e696ea29f4593fe6ce6cfc35 Working as intended
  9. PKHeX's frame detection isn't perfect yet, hence the flagging as fishy if it can't positively verify it. haven't touched it for 10 months: https://github.com/kwsch/PKHeX/commit/3d7b2a2b29664428d53d8ef4e337f35e172a1eae#diff-0b0337837f9d5dc29e00fdcd5c73d009R50 probably not going to take another look at it for a while
  10. Neat fact I'll see what I can add rule-wise; I assume this also applies to the fullwidth numbers on the non-latin keyboards. edit: added! thanks for bringing this up
  11. I'm not going to spend my time curating the list of possible characters. It doesn't require knowledge of PKHeX or the language it's programmed in. Software programs cannot be fed an image or guidelines; things have to be explicit. The program does not have futuristic artificial intelligence to comprehend a nonspecific input, thus requires a human to manually give it the precise list of available characters.
  12. Likely working as intended; you probably don't have any relearn moves set, which doesn't match a bred pkm but instead the gift eevee egg which doesn't have the hidden ability.
  13. Needs to be more explicit than "x language allows for latin characters"; instead needs to be literally a list of every single character (abcdefghijklmnopqrstuvwxyzetc) list for every single language/generation
  14. Sure I'll add something. But you'll have to give me the precise list of allowed characters for every single language, with separate tables for each generation.
  15. If the box storage wasn't already enabled, PKHeX won't enable it automatically. Nobody has figured out how to turn it on.
  16. Was originally added as met location 104 https://github.com/kwsch/PKHeX/commit/afde4514e283acb88c89b9f9c19c7d5138d7ce6e#diff-83a32d69355a64376bc77bd07e338a33R446 I have another save file that uses met location 110 (like this one) so I assume it was originally a copypaste assumption from Sudowoodo. Done, changed by: https://github.com/kwsch/PKHeX/commit/03a05364abeb000ca4cea345631a8fa6396ad7ea
  17. No.
  18. Updated with the changed encounter type.
  19. Party stats are not saved when stored in the box; the game tries to save as much space as possible. IVs are 5 bits each (2^5, 0-31). Can't go any higher. EVs are 8 bits each (2^8, 0-255). Recent games prevent them from increasing past 252. Typing is determined by the ROM's Personal data. You'd have to edit the ROM instead of the save file.
  20. Offset for FRLG should be Block1+0xEE0, not Block2+0x000 PKHeX's current setup for gen3 saves doesn't work for split-chunk operations, so don't expect it to work for flags >1280 (read the recent commit message). I need to figure out how to rework some logic... Edit: fixed with some workaround, should be all good now
  21. The savefile chunks aren't separate, they're just chopped up when saving to the cartridge, and verified in pieces (checksums). block0 = trainer data block1|block2|block3|block4 = savedata stuff block5+ = storage
  22. @theSLAYER : it could be that PKHeX is reading from the wrong offset. https://github.com/kwsch/PKHeX/commit/ee57bc49f066bb6c477df39f2db7aea5f209198c Was added over a year ago; the real 'offset' isn't Block2+0; it's likely Block1+0xE??. Need to get the alignment right. The disassembly of firered's large block doesn't have nearly as much documentation as RS/E (flags, vars).
  23. Nothing made them 'become' illegal. They were illegal to begin with -- PKHeX adds new checks every so often. The legality check has flagged them as follows: Invalid: Incorrectly transferred from previous generation. If you look at the source code, that message is saved as "LTransferBad", which is referenced in one check.
  24. The error message contains details on what went wrong. System.IO.DirectoryNotFoundException: Could not find a part of the path 'C:\Users\Nick\AppData\Local\Temp\380 - Latias - 43D47CF38197.pk7'. at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath) Likely your antivirus is preventing PKHeX from creating temporary files, which are used for facilitating drag/drop.
  25. "Complete" needs to be checked, since you've completed training. It's what the legality message is hinting at.
×
×
  • Create New...