Jump to content

Kaphotics

Helpful Member
  • Posts

    7271
  • Joined

  • Last visited

  • Days Won

    362

Everything posted by Kaphotics

  1. I wrote up some notes back in the day for b2w2 here: https://sites.google.com/site/kaphotics/b2w2-scripting sc_1238 - give item scripts? sc_1241 - ground item scripts If you run the game with an emulator, you can try searching for the script data that is loaded during the event -> find the corresponding script file in the ROM. Keep in mind that there's a difference between stored items and untangible items (like Running Shoes); those would likely just be event/system flags that are set. The give item standard scripts are probably just calling script file 'm', subscript 'n'... ie, CallScript(m, n), which opens script file m and runs the nth script. Not sure if there's a way to pass parameters {CallScript(m,n,o...)}... it's been too long since I've done anything with scripting
  2. Yes. Maybe try restoring original files first and see if that fixes it (before starting completely over).
  3. Again, if you have an extremely aggressive antivirus that is causing other problems, you'll need to keep it disabled or add exclusions so it doesn't mess with pk3DS. If your antivirus stops pk3DS from setting data correctly, you'll get these generic errors every time. Start with a clean ROM dump (so that all files are present as intended), then neuter your antivirus so it stops interfering with the program.
  4. Are you looking for items given by NPCs as part of a script event (not after battle), or ground items (ball/hidden)? Ground items are scripted in a single file if I recall correctly (one of the script files at the end).
  5. The error message is descriptive enough. Value of '9/28/1998 12:00:00 AM' is not valid for 'Value'. 'Value' should be between 'MinDate' and 'MaxDate'. Dates can never be less than the year 2000.
  6. At the beginning. Program loads -> apply dates to any missing. Since you're exporting with the above ^ date, the date is fixed to that date (not the date you set your PC to later). Set your PC date prior to doing any export/edits, ie step 0.
  7. Change the system date before starting the program. When PKHeX starts, it loads all mystery gift data from the executable's data section; if no date is applied to a WC*, it applies one immediately.
  8. Use the latest version of the program, and be sure to have the decrypted exefs in the folder.
  9. Disable your antivirus and run the program as administrator. Likely the antivirus is scanning the repacked files when the program is trying to move the repacked file back into the GARC's folder.
  10. Kaphotics

    bugs

    Working as intended; the pkm you've posted is a Therian, which cannot exist in a B/W save file. PKHeX alerts you to this; you have to load the pkm and re-save it to the save file so that things are within the game's bounds.
  11. It's simple. You change your 3DS to have whatever date you want it to be prior to receiving it from Nintendo's servers. If no date is defined in the download, the console's date is applied to the data prior to saving it to your save file as a wcx. In this case, the data you are trying to add has already had a date set to it. PKHeX isn't arbitrarily choosing a date.
  12. Kaphotics

    bugs

    GTS: already fixed (wait for next release): https://github.com/kwsch/PKHeX/issues/1795 Landorus: Can't tell without seeing the PKM file. Intimidate is a Therian forme exclusive ability, hence the flagging.
  13. Working as intended; receiving a .wcxfull naturally sets the gift date to the current date of the system. You can always have a desync'd 3DS clock, so any date-legality checking you may have been advised on is incorrect. If you can't be bothered with changing your system clock, just import the gift file to the main window and PKHeX will create a Pokémon the same way the game does, after which you can set the date to whatever you want.
  14. Fixed in the latest commit https://github.com/kwsch/PKHeX/commit/f8bf3e400b036c7371b0ebbbba572caa405ad4fb
  15. So those two (well, 4) met locations are not legally obtainable? internal static readonly HashSet<int> ValidMet_USUM = new HashSet<int>(ValidMet_SM) { 194, 196, 198, 200, 202, 204, 206, 208, 210, 212, 214, 216, 218, 220, 222, 224, 226, 228, 230, 232, }; Can remove 194 and 196 if that's the fix that is necessary. Possible that they're unused individualized locations... might not even be worth programming in edge case handling to not merge them.
  16. That sprite is a modified version of Pichu's box sprite; it's not anything found within the games because I manually made a 'new' sprite for Spiky pichu to differentiate in a Box when viewed with PKHeX. Game-exclusive form sprites are retained within PKHeX as it has to support all generations bulbapedia is wrong; someone probably took it from PKHeX and assumed it was the real deal.
  17. The odd-# location IDs don't exist naturally in-game. They serve as a sub-location identifier; PKHeX combines the two to yield the most accurate location.
  18. bool __fastcall Savedata::FieldMenu::IsVisibleRotom(int a1) { return (*(a1 + 0x30) & 0x8000000) != 0; } FieldMenu save chunk is at 0x4600 in US/UM. add 0x30 (-0x4 for memory object) results in 0x462C. Data[0x462F] &= ~(0x08); set the 4th bit of that offset (0x462F) to zero in a hex editor ie 4F -> 47
  19. It should be the same text file as the intro-battle text.
  20. There's a text file that contains battle text messages like giving an item. Not sure which it is. Try looking up a trainer that already gives items.
  21. Again, the ROM hack you are playing is a re-skin with text changes. The overall progression is the same as the official game. You can put your romhack save back on the 3ds and continue through the roadblock, then copy back to the emulator.
  22. that's a default save file that hasn't been saved ingame (no checksum footer). save and close the emulator; and if you really have a problem with an emulator, just play it on your 3DS with your legit game copy since ROM hacks are not advanced enough to have a different story progression.
  23. Opens just fine on the latest version.
  24. Thanks for reporting, fixed in latest commit https://github.com/kwsch/PKHeX/commit/28180687a57c70b369dc9f5f0d14349a462fad41
  25. > current handler could not be OT. Try and interpret what it means. If the pkm was transferred, it is no longer being handled by the OT.
×
×
  • Create New...