Jump to content

Kaphotics

Helpful Member
  • Posts

    6890
  • Joined

  • Last visited

  • Days Won

    322

Everything posted by Kaphotics

  1. PID is illegal. Something is wrong with Pokecheck's check (which I won't say); plus it's highly unlikely that a given spread matches the nature/gender locks. Remember, Pokécheck is not for creating hacked pokemon.
  2. The game uses another function to set trainer flags. sc_1239 has all of the logic for disabling trainers and doing battles. You can probably get away with battling a given trainer, and finding what flag is set after you beat them. memory location of flags
  3. IDs and trash bytes aren't required for routine playthrough or vs friends. a legal pokemon must have legal IDs and legal trash bytes, or else it is illegal (not generatable by the game)
  4. add NPC with kazo's NPCE (or with ), assign it a new scriptadd script with hex editing nobody will hold his hand to guide him through the process though. there's a ton of information available, just not a lot of people actively involved in scripting.
  5. Duh. They're generally in order according to species number. Two palettes per sprite (non&shiny).
  6. Read the sticky in the parent forum. http://projectpokemon.org/forums/showthread.php?24589-B2W2-General-ROM-Info /a/0/0/4 ********* sprites (pokegra)
  7. Trash bytes do not matter for battling against friends or for use in game.
  8. Spinda method (probably) won't work; we currently believe the spots for X/Y origin are based on the encryption constant not the PID.
  9. The Chained Shiny PID method creates shiny PIDIVs with modifications for a loaded ID-SID. http://www.smogon.com/ingame/rng/pid_iv_creation#pid_chained_shiny The X/Y PID-IVs do not match the gen 4 method. So essentially, you started with your answer to receive your answer. Doesn't do any good, I'm afraid.
  10. The 16byte 'checksum' is believed to be what is used to encrypt and decrypt the packet; however it is not yet known how it does it exactly. The 'checksum' has been observed to be 'randomly generated' based off of the contents of the packet header & data, as Zaneris has mentioned. Again, it is unknown how it is generated.
  11. They're no different than regular GBA mons. Same type of trashbytes. Nintendo does not check for trash bytes so importing them to X/Y won't matter.
  12. Trash bytes only originate from pal parking; there are none resulting from being captured/from XDC.
  13. There are no trash bytes from Colosseum / .
  14. They'd never delete an account's data if their trial ends, or if their subscription expires. It's best to keep the data in case the user comes back!
  15. I don't follow. Are you talking about wild held item % chances? Because you can't make them have em 100% of the time without changing the ingame code.
  16. It wouldn't surprise me if the IVs were either 31 or 20. They've done that for gift-trade mons in previous games by just giving them pseudo-static but good IVs.
  17. To recap what's new due to 1.2: That's what it used to be. Now the only difference is that the 0x120 payload of the unk&pkx is never the same (when comparing different instances) because it is encrypted. Image showing a 1.0 packet and a 1.2 packet of the same PKX stored in a box: Speculation:
  18. Duh. You change the item, thus changing the encrypted data... which changes the checksum.
  19. Yes. They're 100% exact data that you would receive had you received them from the event instead.
  20. from gen 5 (shouldn't be that much different) from Pokemon ROM Changer stat boost/drop codes: inflict ailment codes: move categories alternatively, from veekun; https://github.com/veekun/pokedex/blob/master/pokedex/data/csv/move_meta_ailments.csv https://github.com/veekun/pokedex/blob/master/pokedex/data/csv/move_meta_categories.csv https://github.com/veekun/pokedex/blob/master/pokedex/data/csv/move_flags.csv
  21. To absolve any confusion: The way the games determine if its shiny or not is more or less this: (PIDlow^PIDhigh)^(TID^SID)>>3 = 0 -> Shiny [Gen 3-5 origin] (return 0-8191) (PIDlow^PIDhigh)^(TID^SID)>>4 = 0 -> Shiny [Gen VI origin] (return 0-4095) Without the shifts, pre gen6 the XORs had to return a number 0-7. What we noticed in Gen VI is that shinies exhibited 0-15 results, thus the overall odds were doubled. The whole shiny value stuff is a fan simplification since PIDs and Trainer IDs can't be altered by one user, only the OT can be changed (giving a new SIDTID). I don't think anyone has bothered checking xor=16, but there shouldn't be a difference between wilds/breeds. They can always roll extra PIDs if it's not shiny (like genV shiny charm or gen45 MM, or g34 everstones... you get the point)
×
×
  • Create New...