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
line 340 - variable reuse!
In looking at the emerald disassembly, when Pressure/Hustle/Vital Spirit fails, it reduces the max level of the slot by 1 so that the max level doesn't randomly appear. Essentially 50% flat for the max to appear, for varied slots, not 50% + (1/range). Thus we require a separate branch of logic to check for this scenario.
f8119bedd4/src/wild_encounter.c (L298)
DPPt (and assumedly HGSS) do not decrease the random range on failure.
ty TFS for bringing this to my attention on discord
Skip the IsNicknamed evaluation, saving at least 1 string allocation on ctor. Remember the IsNicknamed state when we set false.
GUI: provide the selected language rather than recalculate
silly differences; MethodJ should have been /A3E not %25
Make GetNature public, and have the MethodK esv modulo be uint instead of long for better clarity.
* Added method to extract pokémon data from lilycove museum and experimental way to set paintings active and change their subject in order to obtain 2nd trainer star and crystal decoration
Like with Shiny Zeraora in the past, the only limitation is the distribution of the gift itself. Once added to your Gift Box, it can then be claimed at any time, giving it no end date.
submitting the date based on
- hard copy serial code issued out at Pokemon center in japan on 1st Nov 2024 1000hr (JST)(operating hous : 1000hr), hence countries in the UTC-11 would be able to redeem it on 31th oct 2024 1400hr earliest
- Serial code expiry date is from 1st Nov 2024 - 31th Jan 2026 (JST) or 1st Feb 2026 (UTC+11 )
