#3260 part 1
I searched for more instances of the phantom character, and found the one instance in gen7 zh flags :D
Co-Authored-By: FeralFalcon <33670476+FeralFalcon@users.noreply.github.com>
They cannot be given to a Pokémon to hold in-game. Also label new Pikachu/Eevee Dynamax Crystals.
Co-Authored-By: Lusamine <30205550+Lusamine@users.noreply.github.com>
For BigEndian we don't have to invert the array access if we just iterate backwards :)
Fix xmldoc for gen1 trades ampersand
Add xmldoc for enc trade classes
No functional change.
* Add more memory legality checks
Includes the following new memory checks:
- 4: met in link-trade, allows all possible genlocs except dangerous place
- 7: successful fishing, allows fishable species in gen 6 and 8
- 9: paying attention to another mon, allows only available species for gen 8
- 29: encountering legendary Pokémon, only seen on Zacian, Zamazenta, Calyrex so far
- 32: riding a bike, only in genlocs where biking is possible
- 75: taken to Nursery and placed with a mon, allows only available species for gen 8
Unstubs lotto check and applies it to gen 6.
Co-Authored-By: Skadiv <62726360+Skadiv@users.noreply.github.com>
Co-Authored-By: Matt <17801814+sora10pls@users.noreply.github.com>
* Loto-ID only has one t
* Crown Shrine has another genloc outside
* Consistent Loto name for array
Co-authored-by: Skadiv <62726360+Skadiv@users.noreply.github.com>
Co-authored-by: Matt <17801814+sora10pls@users.noreply.github.com>
Iterate over all possible seed frames that yield the IV pattern; nature is right before IV rands (PID is algorithmic from gender ratio and prior nature call).
Split up GetFrames into stepwise methods, clean up parameter passing
Refer to previous commit, the apply-memory has a 1% chance of failing for 100% memories, resulting in the ability to have 0-memory HT via link trades.
In-game trades caused the previous logic, as those forget to set the HT memory (likely the same logic flaw as skipping the nickname check via game settings).
The middle table in poke_memory.prmb contains the analogue of Gen6's memory table data. All existing memory data is the same, with 20 memories added.
Feeling bitflags are the same as before, but as we've noticed, feeling 0 is not obtainable. All the feelings are value upshifted by 1. This is why the game shows a blank line for Gen6 Feeling-0, as that game was [0,23] not [1,24] for the span of feeling strings.
Memories with 1% chance are actually 0% due to how they if-abort in the game code. Nice bug, GameFreak! @Lusamine had previously committed the unobtainable memories, derived from the community's empirical data.
The Hexagon Brothers can be rematched in Phenac City if their shadows aren't snagged at the Cipher Lab, but Seedot, Houndour, Gulpin, and Spheal are all encountered outdoors (Phenac City (XD) [100]). Mareep and Baltoy are both encountered downstairs in the Mayor's House (Phenac City (XD) [096]).
Relevant .xk3 files: https://cdn.discordapp.com/attachments/537784151970021376/880816626176495626/Phenac_Rematches.zip
Apparently they don't use the bit-permission table in Bank to get a random feeling, and instead just do rand(0,10).
Our logic to set a random feeling for bank transfers is still fine, because we set [0,10) within the bit table.
must have been an oopsie they reverted for international releases
Thanks @liketolike !
Co-Authored-By: Lusamine <30205550+Lusamine@users.noreply.github.com>
#3242
Can definitely be refined as these memories can restrict to capture/hatch/gift encounters. The multi-value arrays can also be restricted for non-hatches too (maybe first element if WasEgg?)
Co-Authored-By: Lusamine <30205550+Lusamine@users.noreply.github.com>
Since we have more metadata with move learn sourcing, we can check if it was traded to gen2 to get new moves / deleted.
Adjust call sites appropriately
might have some issues, to be ironed out maybe
Slap on interface for EntreeSlot
De-magic some 💯 numbers to indicate what they're doing
Improve perf of move-match-relearn check
Add an "else" as valid is never both values (history verifier)
The Encounter verifier method rarely rejects as our inner encounter matching methods are all-or-nothing. Don't bother keeping references for this bloat.
Ran the unit tests and nothing hit this logic.
Old: when an encounter is found, we copied the contents of the list into our analysis list.
Since we stop when we find a suitable encounter, the old list is useless. By sharing the same list, there's no consequence. Reduces allocation by ~56B each analysis object!
Simplification reduces the amount of method calls by 1
