Piñata Vision barcode

From PinataIsland.info, the Viva Piñata wiki
Revision as of 01:19, 18 July 2010 by FeralKitty (talk | contribs) (List possible data in row 2. Add link to Species ID article.)
Jump to: navigation, search


A Tigermisu Piñata Vision card, created with the camera tool. The card has 2 barcode rows.

The barcode for a Piñata Vision card (PVC, or card for short) is based on the EAN-13 barcode, with some minor modifications.

A card's barcode consists of one or more rows of bars. Most cards contain either one or two rows of bars, although a few cards released by Rare contain 3 or 4 rows of bars. No cards have been seen yet with 5 or more rows.

The barcode digits

Each row consists of 113 bars, broken down into sixteen groups of 7-bar patterns (16 x 7 = 112), followed by a single "stop" bar.

The valid barcode patterns (where a 1 represents a black bar, and 0 represents a white space), correspond to a 4-bit value (0-9A-F in hexadecimal), as follows:

This chili card's barcode is F4E079E4CEB7204D.
Bar pattern Hex value Based on EAN-13 digit
1110010 0 R0
1100110 1 R1
1101100 2 R2
1000010 3 R3
1011100 4 R4
1001110 5 R5
1010000 6 R6
1000100 7 R7
1001000 8 R8
1110100 9 R9
1011000 A L0
1001100 B L1
1100100 C L2
1101000 D L9 (not L3)
1100010 E L4
1000110 F L5

The barcode checksum

It's unknown at this point whether a checksum exists as part of the barcode itself, or if the checksum is a part of the encoded data.

It's possible that the checksum is based on some sort of parity, since inverting an even multiple of obfuscated (ID) bits doesn't appear to require a change to any other bits.

The barcode data

To conceal the actual data, the information is obfuscated before being coded as bars. This makes it difficult to recognize cards with sequential or nearly identical data, since their barcodes would appear quite distinct from each other. The obfuscation set article discusses how a particular obfuscation is selected for a card.

Since each barcode row decodes to a sequence of sixteen hexadecimal digits, there are 16x4=64 bits of data per row.

Since the data is obscured differently across the cards, the encoded information (such as ID), will appear in differing bits, depending on the specific obfuscation used for a card. See the Use cost example for an illustration of how (value) bits are obfuscated.

A tab-delimited list of barcodes for the wiki's collection of cards is available to anyone who wants to discover more about the Piñata Vision barcode.

Encoded information

One of the goals of the barcode project is to identify the underlying representation of a card's data.

For example, we know that cards have a use cost, such as 50,000 chocolate coins for a higher-level wildcard. Since the cards have a limited number of bits for data, it's not efficient to store that value as a 32 or 16-bit integer. So that value has to be packed to fit into a smaller (fixed) number of bits reserved for the use cost.

Card type

We know of several different types of cards, such as:

  • Blackariants, GoodVariants
  • Learn/Perform Primary/Secondary Trick
  • PlaceTag Egg, Fruit, Home, Paving, Prop, ...
  • SparseCallback Adjust credits balance, Change dinosaur color, Send in Ruffian, ...
  • Timewarp
  • UnlockArt
  • UnlockTag TrickStick
  • View Appear Cutscene, House Interior, Mate Cutscene
  • ViewTagInJournal
  • Weather
  • Romance music tracks (proper name of card type unknown?)

Each of these types of cards may share some data that's common to all cards (such as a card type field, checksum, or perhaps an ID). Other data might be unique to a particular type of card, such as the color of dinosaur, or type of weather or trick stick.

The card type is possibly a key field that tells the game what type of data follows. The card type example gives a quick visual glance of cards with differing type bits.

ID

Some of the developer cards include a number near the end of the filename, e.g., Vision_Single_PlaceTag_Home_parrot_586.jpg. This value, 586, appears to be an ID value that identifies the card's item to the game. In short, the barcode likely says "Place item 586 (a Parrybo home) into the garden (for free)."

It's not apparent if the type of item (e.g., Home, Egg, Fruit, Paving, Prop, ...) is also encoded on the card, or if the ID functions alone as an index into an ID table consisting of many types of items.

Since the largest ID seen so far is 2249, it's likely that the ID field is 11 bits long.

Low-value IDs (0-160?) appear to serve as species IDs, with several different types of cards sharing a common species (e.g. unlock art for Raisant, view journal for Raisant, learn trick for raisant, ...).

Use cost

Player-created cards have a use cost associated with them, and the game will display the cost as part of a prompt, when asked if you want to use the card. The use cost is also shown at VivaPinata.com, when looking at a specific card.

Use cost representation
Value Magnitude Use cost
6 0 6x1=6
65 0 65x1=65
100 0 100x1=100
65 1 65x10=650
65 2 65x100=6500

Since the cost could be a large value for an expensive pinata, the cost is encoded on the card as a smaller value, and a magnitude (power of 10).

Smaller values (likely less than 128) are represented as that value, with a magnitude of 0 (10^0 = 1). Larger values such as 650, are represented as 65, with a magnitude of 1 (10^1 = 10)

The value is likely a 7-bit field. The magnitude is possibly a 3- or 4-bit field. This representation supports packing large use costs (millions or billions of coins) into a far-smaller field than a 32-bit integer would use.

One further note about the use cost is that some (developer) cards are free to use. It's likely that they have a use cost of 0.

The Use cost example illustrates how it's possible to find known information within an obfuscated card's data.

Other fields

There's certainly more data that's stored on the card, depending on its type. For example, some cards contain a pinata's name (e.g., Image:Chewnicorn-TroubleInParadise-Black-Francesca-PV.jpg. That particular card type also appears to contain a (4-bit?) variant color field that's likely shared between the Blackariants and GoodVariants card types.

Other examples of data on a card are optional accessories that a pinata might be wearing, a gamertag if the card happens to be locked, or the type and duration of weather that the game should feature.

Goals

Short-term goals

Discover the unreleased Choclodocus egg card

The Choclodocus egg card was discovered on May 3, 2010 by shrly, who volunteered to help scan cards for the barcode project.

This project has ended. Read more about it.

Discover the unreleased amber gem card

The amber gem card was discovered on May 10, 2010 by shrly, who volunteered to help scan cards for the barcode project.

This project has ended. Read more about the method used for its discovery.

Discover the "Change dinosaur color to 3" card

We already have three Choclodocus cards for color 0, 1, and 2. It's definite that there's an unlocked neon green reskin card, which may be color 3. Perhaps by identifying the bits used to store the color value, we can turn one of those cards into a color 3 card.

This project is not yet underway, but any member is welcome to start working on it.

Long-term goals

Discover more about the encoded data fields

Examples of what's left to do, are:

  • Learning about the card type field (4-bits?),
  • the wildcard field (2-bits?, trait 1, 2, 3, or normal?),
  • the variant field (2 4 bits? 0-15, black is 15?),
  • the gamertag field,
  • the locked card bit,
  • the accessories field,
  • the checksum, and
  • various other type-specific fields, such as:
    • weather type, duration
    • romance music track
One-row cards
  • Normal species (non-variant, non-wildcard)
  • Vision_Single_PlaceTag cards (These plants are one-row)
Two-row cards
  • SpeciesPV cards (species + 3 accessories)
  • Learn/Perform Trick
  • Romance Music
  • Species wildcards
  • Species variants (in-game, Blackariants, and GoodVariants)
  • Plants (user-created plant cards are 2-row unlike PlaceTag plants)
  • Named species (Blackariants and GoodVariants, but likely also named normal species and/or wildcards)
  • Locked dino cards
Possible data (fields) in row 2
  • Wildcard trait (2 bits? values 0-2? 1-3?)
  • Variant color (4 bits? values 0-15? Black is apparently 15)
  • Name (? bits. 9 character values, i.e., Francesca. 8 character values, i.e., Scarlett, Isabella, Benjamin, Harrison)
    • Accented characters? Unicode (e.g., Japanese)?
  • Accessories (? bits.)
  • Gamertag (? bits. Unique integer? Hash? Alphanumeric?)
    • A gamertag can be 15 characters max... acceptable chars are Aa-Zz, 0-9, single spaces, and it can't start with a number.

Read cards to dump their data

Currently the reader script can dump ID and use costs for some of the obfuscation sets. Eventually, it would be nice to dump all the data about a card into some human-readable format.

Generate cards

As the project continues and the community learns and shares more about the barcode, we'll be able to identify more of these fields, and eventually generate our own cards for pinatas with specific traits, colors, names, and so on.

How you can help

  • Help scan recently discovered cards to ensure that they're 100% valid before being announced to the community.
  • Learn more about the barcodes on your own, such as by deciding on an interest (e.g., the card type field)
  • Start the hunt for a specific card, or to learn more about specific card data (such as the card type field). Try one of the documented discovery methods, or come up with a different approach to discovering more about the barcode.
  • Mail your locked neon Choclodocus reskin card to pinatavision at gmail dot com to help with future discoveries. More details and answers can be found at the forum.

See also