Attack of the Vine is now available in the simulator!

Open packs

Lorcana guide

Lorcana Pack Simulator Methodology

A transparent explanation of the frontend-visible Lorcana simulator data flow, pack model, box mode, collection storage, and limitations.

Last reviewed 5 August 202610 min read

This page documents what can be verified from the current Lorcana Pack Simulator frontend. It is intentionally conservative: the frontend repository can show API contracts, generated snapshots, display utilities, and local collection behaviour, but the exact backend pack-generation code is outside this workspace.

Data sources visible to the frontend

The API client uses a Lorcana API base URL and calls endpoints for sets, set details, set cards, chase cards, card search, opening packs, simulating pull rates, and stats. The live pack opener depends on `POST /api/v1/open-pack`; booster-box mode uses the same endpoint with box options.

The frontend also contains a generated prerender snapshot. That snapshot stores public set and card data used to render useful static HTML for crawlers and fast initial page loads. After the page loads, many pages refresh from the API when available.

Pack-pullable cards

Set records include fields such as `pack_pullable_count`, `total_printings_count`, and `total_cards`. Card records in the generated data include `is_pack_pullable` when that field is available. The frontend uses those fields to decide whether a set can be displayed, whether pack-opening controls should be enabled, and how to describe set checklist totals.

The actual card pool selected during a pack opening is returned by the backend. If pack-pullable flags or rarity fields are wrong in the database, the frontend can only display the result it receives.

Pack structure and rarity slots

Existing frontend pages describe the current simulator pack structure as 12 cards: 6 Common slots, 3 Uncommon slots, 2 rare-plus slots, and 1 foil or special slot. Rare-plus means the simulator can draw from Rare, Super Rare, Legendary, and supported set-specific rarities.

The generated pull-rate model includes rare-slot weights for Rare, Super Rare, Legendary, and Epic, plus per-set overrides. In the current snapshot, the Fabled set code has an override that allows Epic in rare-plus slots. These are simulator settings, not official pull rates.

Foils and chase behaviour

The frontend treatment utilities identify regular, foil, cold foil, alternate art, Epic, Enchanted, and Iconic outcomes from rarity, foil type, variant type, and alternate-art fields. Pull recap sorting ranks Iconic, Enchanted, alternate art, Epic, Legendary foil, Legendary, and other rarities ahead of everyday cards.

The generated model includes unofficial chase-rate settings for Enchanted, Legendary foil, Epic, Iconic, and alternate art. Existing public pages describe Enchanted and Iconic as foil-or-special-slot outcomes. Those rates are estimates used for simulation and should not be quoted as official odds.

Booster boxes

The frontend requests booster-box mode with a `boxSize` of 24 and `useBoxOdds` enabled. It then receives packs from the API, keeps unrevealed packs hidden, reveals them on interaction, and summarizes cards from opened packs only.

The pull-rate page and generated model describe box-level rare-slot and foil-slot count choices. For example, the model stores weighted count choices for Super Rare, Legendary, Epic, and higher-rarity foil outcomes. That means the simulator can target a box-level mix rather than treating every slot as a fully isolated roll. This is a modelling assumption, not a real-box guarantee.

Collection tracking

Collection progress is stored locally in the browser through the collection storage utility. Revealed cards can be added after pack or box reveals, and the collection page reads that local data to show owned and missing cards. There is no frontend account flow or cloud sync for collection progress.

Because local storage belongs to the current browser, collection data can disappear if the user clears browser data or uses another device. The privacy page should be read for the site's broader browser-storage and analytics notes.

Known limitations

  • The frontend cannot verify physical collation patterns, print-run changes, or regional product differences.
  • The simulator depends on imported database fields for rarity, treatment, image, set assignment, and pack-pullable status.
  • Generated prerender data may lag behind the live API until the site is rebuilt.
  • Search results, opened packs, and collection filters are dynamic utility states rather than separate editorial pages.
  • Odds are unofficial estimates for this simulator and are not endorsed by Disney, Ravensburger, or Disney Lorcana.

Reporting data issues

If a card image, rarity, set assignment, foil treatment, collector number, or simulator result looks wrong, use the Contact page and include the set name, card name, collector number, and what appears incorrect. That is the most useful information for checking imported data against the current simulator behaviour.

Frequently asked questions

Does the frontend generate packs by itself?

No. The frontend calls the backend pack-opening API and renders the returned pack or box result.

Where is collection progress stored?

Opened cards are saved to local browser storage on the current device. The current frontend does not require an account for collection tracking.

Are the odds official?

No. The methodology documents this simulator's unofficial model and limitations. It does not claim official Disney or Ravensburger pull rates.