Difference between revisions of "Piñata Vision barcode"

Revision as of 22:37, 14 February 2011

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.

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)."

All PlaceTag cards seem to be a single card type, regardless of type of item (e.g., Home, Egg, Fruit, Paving, Prop, ...), since it's possible to change the (type of) item merely by changing an ID bit. The ID appears to serve 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.

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.

There does seem to be some variance on how a use cost such as 1000 is encoded. Looking at use costs for obfuscation set A, 2 cards have encoded 1000 as 100 x 10, while 2 others have it encoded as 10 x 100.

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 an early example of finding 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 name field (e.g., Image:Chewnicorn-TroubleInParadise-Black-Francesca-PV.jpg. That particular card type also appears to contain a variant 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.

Discover the unreleased red sour cards

We have cards for black variant sours, but no released ones for the red sours.

This project has started. Read more about it.

Long-term goals

Discover the garden store card

This building is missing from the PlaceTag cards.

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

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 and name length (5 bits (name length) + namelen x 7? bits)
  • 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, use costs, name length, name, and variant data 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

• Volunteer to scan generated cards, to see what, if anything, turns up. Maybe you'll be the member who makes the next big discovery. You can volunteer by signing up in the forum's Unlocking the Secrets of the Pinata Vision Barcode thread.

• 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

• List of barcodes