import_data assigns the newest Generation to auto-created packs instead of the set's generation #4
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
`apps/tracker/management/commands/import_data.py` (around line 205): when a card references a pack that does not exist yet, the pack is created with
i.e. always G4 on current data, even though `pset.generation` is right there and `data/sets.csv` already carries the correct generation per set. On a fresh import every pack of A1..A4b gets G4's pack types and probability tables: 5-slot tables for the 4-card A4b pack, and a 5.2%-weighted "shiny pack" with a slot-6 shiny-only distribution applied to G1 sets that have no shiny cards (which, combined with the dropped-mass behaviour in utils.py, pushes that pack type's chance to 100%).
`update_pack_generations` does not fix this; it only maps legacy v1..v4 names to G1..G4.
Fix: `rarity_version=pset.generation` (and fail/skip loudly if the set has no generation).
Confirmed by the repo owner: after every import the generation has to be set by hand. Code-wise,
import_setsdoes read thegenerationcolumn fromdata/sets.csvand setsPokemonSet.generationcorrectly (generations are imported before sets, and the admin "Import Data" button runs the same full command). The part that is never set correctly isPack.rarity_version, which is whatprob_at_least_one_new_cardand the pack list actually use: it is always the newest Generation (order_by("-name").first()), regardless of the set. The manual fix in the Pack admin is working around exactly this line. Fix is stillrarity_version=pset.generationwhen creating the pack, plus updatingrarity_versionon existing packs whose set generation differs.