[feat]: Add pull-rate types and derive rates#1384
[feat]: Add pull-rate types and derive rates#1384FalconChipp wants to merge 11 commits intomasterfrom
Conversation
Introduce pull rate support across the codebase: add PullRateValue, SpecialVariantPullRate and PullRates types and extend Set/Card interfaces (interfaces.d.ts, meta API types). Add example pullRates data to a sample set file. Implement deriveCardPullRates util to compute card.pullRate and variantPullRates from set.pullRates (server/compiler/utils/pull-rates.ts) and wire it into card compilation (cardUtil.ts). Expose set.pullRates in set output (setUtil.ts). This enables defining rarity and special-variant odds at the set/booster level and deriving per-card rates at compile time.
🃏 7 Cards ChangedDetails: 7 modified Mega Froslass ex (me02.5-265) (found using en)
File: [data/Mega Evolution/Ascended Heroes/265.ts](https://github.com/tcgdex/cards-database/blob/ea250f37d4e02a922a8a52ae2ce4b214cec9e833/data/Mega Evolution/Ascended Heroes/265.ts) Mega Eelektross ex (me02.5-266) (found using en)
File: [data/Mega Evolution/Ascended Heroes/266.ts](https://github.com/tcgdex/cards-database/blob/ea250f37d4e02a922a8a52ae2ce4b214cec9e833/data/Mega Evolution/Ascended Heroes/266.ts) Mega Diancie ex (me02.5-267) (found using en)
File: [data/Mega Evolution/Ascended Heroes/267.ts](https://github.com/tcgdex/cards-database/blob/ea250f37d4e02a922a8a52ae2ce4b214cec9e833/data/Mega Evolution/Ascended Heroes/267.ts) Mega Hawlucha ex (me02.5-268) (found using en)
File: [data/Mega Evolution/Ascended Heroes/268.ts](https://github.com/tcgdex/cards-database/blob/ea250f37d4e02a922a8a52ae2ce4b214cec9e833/data/Mega Evolution/Ascended Heroes/268.ts) Mega Gengar ex (me02.5-269) (found using en)
File: [data/Mega Evolution/Ascended Heroes/269.ts](https://github.com/tcgdex/cards-database/blob/ea250f37d4e02a922a8a52ae2ce4b214cec9e833/data/Mega Evolution/Ascended Heroes/269.ts) Mega Scrafty ex (me02.5-270) (found using en)
File: [data/Mega Evolution/Ascended Heroes/270.ts](https://github.com/tcgdex/cards-database/blob/ea250f37d4e02a922a8a52ae2ce4b214cec9e833/data/Mega Evolution/Ascended Heroes/270.ts) Mega Dragonite ex (me02.5-271) (found using en)
File: [data/Mega Evolution/Ascended Heroes/271.ts](https://github.com/tcgdex/cards-database/blob/ea250f37d4e02a922a8a52ae2ce4b214cec9e833/data/Mega Evolution/Ascended Heroes/271.ts) |
FalconChipp
changed the title
Move pull rate derivation from the card level to individual variants. Add pullRate to variant_detailed in the API types, update internal interfaces commentary, and remove card-level pullRate/variantPullRates fields. Replace deriveCardPullRates with deriveVariantPullRate in server code and attach the derived pullRate to each variants_detailed entry in cardToCardSingle.
Convert pullRates entries in Ascended Heroes from plain strings to objects with display and numeric percent values (e.g. { display: '1 in 5', percent: 20 }) and update specialVariants.rate to the same shape. Update PullRateValue in interfaces.d.ts to require percent so code can rely on a numeric probability for calculations
FalconChipp
changed the title
Update Ascended Heroes set data and interfaces to reflect corrected rarities and pull-rate rules.
Allow for specialVariations to be undefined if no data is available
Replace Partial<Record<string, string>> with Record<string, unknown> for specialVariants in meta/definitions/api.d.ts. This broadens accepted value types for variant properties (no longer limited to strings) while keeping the required rate field, preventing type errors when variant values are non-string.
Introduce typed PullRateValue and PullRates in API definitions and add an optional Card.pullRate field. Implement deriveCardPullRate and refine deriveVariantPullRate to resolve rarity- and variant-level pull rates from a set. Populate card.pullRate when serializing cards and expose set.pullRates (rarities + mapped specialVariants) in set serialisation.
|
How are you sourcing your pull rate data? I have been doing my best to collect pull rate data for some time in order to power my Tabletop Simulator based Pack Simulator, and for ASC especially I have compiled an N of nearly 20000 for most slots, and the provided numbers don't come close to mine ( quick reference, source spreadsheets ), in particular your pull rate for MHRs is nearly twice mine (over 1/1000). I also question the methodology here: we do not have official pull rates, and have not since the wizards era. Every bit of data we have has to be collected from samples, and is thus subject to statistical uncertainty, and for older sets our data is very limited, often to rumors and forum heresay. The idea of an authoritative source for this is questionable, and having nothing to back it up makes it little better than the old forums. If I was to do this, I would collect and format the data differently. Instead of collecting rates in the API, I would store samples, and then have a script regularly (no reason to do this in real time) process those samples into usable rates with sample size provided for uncertainty calculations, with users being able to submit their recorded (as in video recording with the box being opened on stream, to avoid manipulation and scaling) samples to add to the store. This is of course a great undertaking, but underlines that I don't think what is happening in this PR is good practice. |
|
This PR is for adding pull rate fields, not for building an entire audited community statistics platform. I’m not claiming pull rates are official or perfectly authoritative. Obviously modern physical pull rates are sample-based unless explicitly published. That is not some revelation, and it does not make the feature inherently bad practice. If the Ascended Heroes figures are off compared to your data, then the useful part of that comment is the data difference. The rest of it is basically arguing for a completely different project and pretending that has to exist before this feature can exist at all, which I don’t agree with. Also worth pointing out that the initial data in this PR was pulled together from several sources and a middle ground was chosen between them. It is not intended to represent final locked-in data, it is there to represent the shape and usage in the PR. If you have stronger numbers and are willing to share the methodology/source, that is useful. But “I would architect a much bigger system for this” is not the same thing as this PR being bad practice and frankly outside the scope of what the api is. |
|
Sorry if I over-reacted, I get twitchy with data management and sources in a post-AI world, and suspected a hallucination in the data or vastly insufficient sample size as I have never recorded MHR rates that good after summing my sources. As for sharing data, I am very happy to and already have via the links sent in my first comment. I typically collect my data from known pack opener posts and, in times of need, watching box opening streams and recording the results, what I have is in the spreadsheet linked. I've been at this a while and have been compiling sources since pull rate posts started becoming popular over covid, and have personally invested sets that did not have any data at all or who had poor data availability. My suggestion for a new system is simply trying to make a data driven approach for what I consider to be subjective and thus challangable data. If you're not willing to do that, then at least posting what sources you do have would do a lot to address the underlying concerns. |
|
Again, as stated in my last comment, the data used for the single set in this PR is not intended to be the final representation of the data. It is there to demonstrate the shape and usage of the field in the PR. And as also already stated, a full community validation/reporting system with automated checks is far outside the scope of what this API is. |
3 participants
Add Phase 1 pull rate support
Introduces set-level pull rate data and derives it onto card variants at compile time.
New types (interfaces.d.ts, meta/definitions/api.ts)
PullRateValue — a display string or { display, percent } object for sortable/calculable rates
SpecialVariantPullRate — a variant match rule with an associated rate
PullRates — container for rarity rates and special variant rules
Data model changes
Set.pullRates — source of truth for set-level odds
Set.boosters[x].pullRates — optional per-booster override
Pull rates are authored on sets only, never on individual cards
Derivation (pull-rates.ts)
deriveVariantPullRate — matches a card variant against set.pullRates.specialVariants using explicit match fields; first match wins
Wired into cardUtil.ts — each variants_detailed entry gains a pullRate field at compile time
Output changes
set.pullRates passed through in setUtil.ts
variants_detailed[].pullRate populated on cards from sets with pull rate data