Closes#4404
Future improvements can add value ranges to restrict based on PIDs (e.g. M1 Wish must be below X, M4 must be above Y, or if it's a range, likewise. Or, if it's a certain %24 result for shuffling considerations).
Co-Authored-By: notblisy <50887637+notblisy@users.noreply.github.com>
Clone'd saves no longer retain same byte[] refs as original
evident in GUI editors and canceled changes somehow being saved
(gen3 isn't required, because it's unpacked into the blocks, but just be consistent)
Previously would only generate with minimum levels when IVs are provided
Now that it generates not-min levels, need to set the correct level.
Might be possible in the future to have IV-spec also respect a Level request, but for now it's only forceMin which nobody currently uses (no usage of the setter).
Extract better signatures for BallApplicator.ApplyBallLegalRandom
Slot1: swap interface order (consistency with other classes, no impact)
IEncounterTemplate vs IEncounterable interface usage
Previous logic would check a new LegalityAnalysis for each ball attempted, and would additionally allocate a new PKM for testing the balls.
With the refactoring to BallVerifier, we can just pass in the template and ball and get a truth, skipping the entire re-check. There might be a deficiency when the current ball invalidates the encounter (GO) but I don't think that's worth considering at this time.
pkmnclassic has recently had some pokemon traded that cause game
crashes when viewing the pokemon's information, or when trying to
remove the pokemon for these boxes. most of these pokemon were reported
legal by pkhex however. this fixes the biggest use of these we've seen
actively traded (some of the other checks require more validation, as
they seemed to be buggy, we intend to validate those & send more PRs if
needed).
this check effectively covers "NULL Bytes" within the trainers name,
or the pokemon's nickname. We have attached an example pk4 that was
traded through our service that exhibits this issue, a couple notes:
- Generation 5+ seem to not be affected and replace character names with
'?'
- Not all screens crash inside of Generation 4, the big ones our users
noticed were viewing the pokemons information, and removal from the
boxes.
- I also got a crash in pokemon ranch, but my testing setup was pretty
hacky, and I'm not confident it wasn't something else, but we know
it's potentially possible.
- We check for the terminator character '\uffff' which the pkhex string
converter inserts implicitly when encountering an invalid character,
but the actual underlying character when performing a hex dump is
`\0`.
HGSS tracks each box if it is changed, to skip writing it on in-game save. PKHeX (and other editors) weren't updating these bitflags, so when empty boxes had Pokémon added and saved once in-game, the save file would corrupt as it was copying the checksum but not the box's data.
Saving twice in-game will cause the checksums to get updated even without the flags being set. I don't think we understand it fully, but this hacky workaround of noting all boxes as "changed" will cause the first-save to properly copy all contents of the boxes to the new primary save section. Rather than tracking which boxes we are reading/writing slots for, or fixing/comparing against a backup -- we need to account for API usage where people might write directly into the save (pcdata.bin/boxdata.bin too). Best to play it safe and let the game fix it.
Most wouldn't have noticed this issue as the box they're modifying is usually their most-recently-changed in-game box.
Closes#4368
`ListControl._dataManager` is null until some event fires, which never happens until the Visible state is normally triggered by flipping to that tab.
The met tab Version/Location can skip Visibility changes on startup, resulting in never being initialized by the GUI framework, thus ignoring any calls to change SelectedValue. Really weird, but setting the BindingContext here forces it to create a `_dataManager` when setting a new `DataSource`.
Closes#4384
