Difference between revisions of "Piñata Vision barcode"

From PinataIsland.info, the Viva Piñata wiki
Jump to: navigation, search
m (Update status of red sour cards project)
m (Add link to sample decoder script)
 
(13 intermediate revisions by the same user not shown)
Line 53: Line 53:
 
=== The barcode checksum ===
 
=== 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.
+
Each barcode row consists of 15 digits, plus a check digit.  (The check digit also identifies the specific method used to obfuscate that row's 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 Piñata Vision barcode checksum is based on the EAN check digit.  Alternating weights of 3 and 1 are used, with the 15th digit having a weight of 3.  The weighted values are summed.  The check digit is the value which when added to the sum yields a number evenly divisible by 16.  (I.e., modulo 16 of the sum plus the check digit will equal 0.)
 
=== The barcode data ===
 
=== The barcode data ===
  
To conceal the actual data, the information is [[Wikipedia:Obfuscation|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 [[Piñata Vision barcode/Obfuscation set|obfuscation set]] article discusses how a particular obfuscation is selected for a card.
+
To conceal the underlying data, the information is [[Wikipedia:Obfuscation|obfuscated]] (on a per-row basis) 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 [[Piñata Vision barcode/Obfuscation set|obfuscation set]] article discusses how a particular obfuscation is selected for a card.
  
Since each barcode row decodes to a sequence of sixteen [[Wikipedia:Hexadecimal|hexadecimal]] digits, there are 16x4=64 bits of data per row.
+
Each barcode row decodes to 16x4=64 bits of data.  The first 60 bits are encoded data.  The last 4 (least significant) bits per row are used for the checksum/obfuscation set.
  
 
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 [[Piñata Vision barcode/Use cost example| Use cost example]] for an illustration of how (value) bits are obfuscated.
 
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 [[Piñata Vision barcode/Use cost example| Use cost example]] for an illustration of how (value) bits are obfuscated.
Line 71: Line 70:
 
One of the goals of the barcode project is to identify the underlying representation of a card's data.
 
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.
+
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 large values as 32- or 16-bit integers.  So a use cost value has to be packed to fit into a smaller (fixed) number of bits reserved for the use cost.
 +
 
 +
===== Payload type =====
 +
 
 +
Although there are many different types of cards, the [[Piñata_Vision_barcode/Encoded_data#Payload_type|payload type]] groups the many similar sets of cards together into a small number of common types for the game to process.  The payload type field itself is 5 bits.
  
===== Card type =====
+
The payload type is the key (most significant) field that tells the game exactly what type of data follows.  Sub-type values can be found further within the encoded data so the game can distinguish between similar cards such as Appear cutscene and Mate cutscene.
  
We know of several different types of cards, such as:
+
The three different card types seen so far are grouped as follows:
* 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.
+
* Cards which drop an something into the garden:
 +
** PlaceTag
 +
** Blackariant
 +
** GoodVariants
 +
* Cards which reference a pinata or item:
 +
** Learn/Perform Primary/Secondary Trick
 +
** UnlockArt
 +
** Journal
 +
** Appear and mate cutscene
 +
** Other cards likely included within this card type would be House interior
 +
* Cards which perform an independent action:
 +
** Sparse callback (e.g., adjust credits balance, change dinosaur color, send in Ruffian)
 +
** Romance music tracks (official name of card type unknown)
 +
**Other cards likely included within this card type would be Weather and Timewarp
 +
* Cards which reskin the trick stick.
  
The card type is possibly a key field that tells the game what type of data follows.  The [[Piñata Vision barcode/Card type example|card type example]] gives a quick visual glance of cards with differing type bits.
+
The [[Piñata Vision barcode/Card type example|card type example]] gives a quick visual glance of cards with differing type bits.
 +
 
 +
Each of these types of cards may share some data that's common to most cards (such as an ID).  Other fields might be unique to a that particular card type, such asthe color of dinosaur, or type of weather.
  
 
===== ID =====
 
===== 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)."
+
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, is an ID value that identifies the card's item to the game.  In short, the barcode 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 [[Piñata Vision barcode/ID table|ID table]] consisting of many types of items.
+
All PlaceTag cards are a single payload type, regardless of type of item (e.g., Home, Egg, Fruit, Paving, Prop, ...), and 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 [[Piñata Vision barcode/ID table|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.
+
Since the largest ID seen so far is 2249, it's likely that the ID field is 12 bits long.  This has been verified by observing that ID bit 11 immediately follows the payload type field for ID bits.
  
Low-value IDs (0-160?) appear to serve as [[Piñata Vision barcode/SpeciesID table|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, ...).
+
Low-value IDs (0-160?) appear to serve as [[Piñata Vision barcode/SpeciesID table|species IDs]], with several similar types of cards utilizing a common species ID (e.g., unlock art for Raisant, view journal for Raisant, learn trick for Raisant).
  
 
===== Use cost =====
 
===== Use cost =====
Line 126: Line 134:
 
Larger values such as 650, are represented as 65, with a magnitude of 1 (10^1 = 10).
 
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.
+
The value is a 7-bit field.  The magnitude is a 3-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 [[Piñata_Vision_barcode/Obfuscation_set/A#Use_costs_read_from_obfuscation_set_A|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.
 
There does seem to be some variance on how a use cost such as 1000 is encoded.  Looking at [[Piñata_Vision_barcode/Obfuscation_set/A#Use_costs_read_from_obfuscation_set_A|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.
+
One further note about the use cost is that some (developer) cards are free to use.  They have no encoded use cost value at all.
  
 
The [[Piñata Vision barcode/Use cost example|Use cost example]] illustrates an early example of finding known information within an obfuscated card's data.
 
The [[Piñata Vision barcode/Use cost example|Use cost example]] illustrates an early example of finding known information within an obfuscated card's data.
Line 138: Line 146:
 
There's certainly more data that's stored on the card, depending on its type.  For example, some cards contain a [[Piñata_Vision_barcode/Name_bits|name field]] (e.g., [[:Image:Chewnicorn-TroubleInParadise-Black-Francesca-PV.jpg]].  That particular card type also appears to contain a [[Piñata_Vision_barcode/Variant_bits|variant field]] that's likely shared between the Blackariants and GoodVariants card types.
 
There's certainly more data that's stored on the card, depending on its type.  For example, some cards contain a [[Piñata_Vision_barcode/Name_bits|name field]] (e.g., [[:Image:Chewnicorn-TroubleInParadise-Black-Francesca-PV.jpg]].  That particular card type also appears to contain a [[Piñata_Vision_barcode/Variant_bits|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.
+
Other examples of data on a card are [[Piñata_Vision_barcode/Accessory_bits|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 ==
 
== Goals ==
Line 158: Line 166:
 
==== Discover the "Change dinosaur color to 3" card ====
 
==== 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.
+
The [[:Image:Choclodocus-TroubleInParadise-EliteNeon-Unsupported-PV.jpg|elite neon green reskin card]] was discovered on April 5, 2011 by FeralKitty.
  
This project is not yet underway, but any member is welcome to start working on it.
+
This project has ended.
  
 
==== Discover the unreleased red sour cards ====
 
==== Discover the unreleased red sour cards ====
  
We have cards for black variant sours, but no released ones for the red sours.
+
We have Rare's cards for black variant sours, and have now discovered all the red sour cards.
  
This project has started.  [[Piñata Vision barcode/Pest_cards|Read more about it]].
+
This project has ended.  [[Piñata Vision barcode/Pest_cards|Read more about it]].
 +
 
 +
==== Discover the remaining romance music cards ====
 +
 
 +
We have a few [[:Category:Jukebox_track_cards|jukebox track cards]] that Rare has released.  It would be nice to generate barcodes for the remaining species.
 +
 
 +
This project is not yet underway, but any member is welcome to start working on it.
  
 
=== Long-term goals ===
 
=== Long-term goals ===
Line 178: Line 192:
 
==== Discover more about the encoded data fields====
 
==== Discover more about the encoded data fields====
  
Examples of what's left to do, are:
+
Now that the barcode data has been deobfuscated, some details have been discovered about the [[Piñata_Vision_barcode/Encoded_data|encoded data]].  Remaining data to be decoded includes:
 +
 
 +
{| class="navbox" cellpadding="0" cellspacing="3" style="border: 1px solid #aaa; padding:0; width:200px; margin:0; float:right;"
 +
|-
 +
! style="background-color:#ccf; text-align:center; padding:0;" |Discovered data
 +
|-
 +
| style="background-color:#f9f9f9; text-align:left; font-weight:normal; margin:0; position:relative; padding-left: 1em; padding-right: 0em;" |
 +
* [[Piñata_Vision_barcode/Accessory_bits|Accessory bits]]; [[Piñata_Vision_barcode/Encoded_data#Accessory_flag|accessory flag]]
 +
* [[Piñata Vision barcode/Obfuscation set#Obfuscation set selection|Checksum]]
 +
* ID
 +
* [[Piñata_Vision_barcode/Name_bits|Name bits]]; [[Piñata_Vision_barcode/Encoded_data#Name_flag|name flag]]
 +
* Use costs; [[Piñata_Vision_barcode/Encoded_data#Use_cost_flag|use cost flag]]
 +
|}
  
* Learning about the card type field (4-bits?),
+
* Learning about the remaining payload types (5-bits),
* the wildcard field (2-bits?, trait 1, 2, 3, or normal?),
+
* the wildcard field (2-bits, trait 1, 2, 3, or normal?),
* the variant field (<del>2</del> 4 bits0-15, black is 15?),
+
* the [[Piñata_Vision_barcode/Variant_bits|variant field]] (<del>2</del> 4 bits, 0-15, black is 15),
 
* the gamertag field,
 
* the gamertag field,
* the locked card bit,
+
* <del>the locked card bit,</del>
* the accessories field,
+
* a "instantly reusable" bit, and
* the checksum, and
 
 
* various other type-specific fields, such as:
 
* various other type-specific fields, such as:
 
** weather type, duration
 
** weather type, duration
Line 211: Line 236:
 
* Wildcard trait (2 bits?  values 0-2?  1-3?)
 
* Wildcard trait (2 bits?  values 0-2?  1-3?)
 
* [[Piñata_Vision_barcode/Variant_bits|Variant color]] (4 bits? values 0-15?  Black is apparently 15)
 
* [[Piñata_Vision_barcode/Variant_bits|Variant color]] (4 bits? values 0-15?  Black is apparently 15)
* [[Piñata_Vision_barcode/Name_bits|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?)
 
* 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.
 
** A gamertag can be 15 characters max... acceptable chars are Aa-Zz, 0-9, single spaces, and it can't start with a number.
Line 219: Line 241:
 
==== Read cards to dump their data ====
 
==== 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 [[Piñata Vision barcode/Obfuscation set|obfuscation set]]s.  Eventually, it would be nice to dump all the data about a card into some human-readable format.
+
Currently the reader script can dump payloads for ID, use costs, name, accessories, wildcard and variant data, and several other fields for all of the [[Piñata Vision barcode/Obfuscation set|obfuscation set]]s.  Eventually, it would be nice to decode all the data about a card (e.g., accessory items) into a human-readable format.
 +
 
 +
{| class="collapsible collapsed"
 +
!Sample payload data from the reader script
 +
|-
 +
|
 +
{|
 +
<pre>
 +
% ./barcodetxt2bitdiff.pl --short < barcodes.txt | egrep '(RaisantHome|02-Goobaa|Christmas)' | ./reader.pl --parse --verbose
 +
RaisantHome        502 B1D5D1C45F6ECF18
 +
00000: Start of data
 +
00001/ID: 502
 +
10110/Reuse: 00001
 +
11000/UseCost: 500
 +
00000: End of data
 +
 
 +
02-GoobaaPV        108 8694B4C37FF5ED8895AC845BE84BDD4C2AE67C7BE7660C2D
 +
00000: Start of data
 +
00001/ID: 108
 +
11101/Accessory: 3 items 43 103 80
 +
00111/Name: Bigsheep
 +
01010/Variant: 2
 +
00000: End of data
 +
 
 +
Christmas-12.25.2008 28 B18177A5BDFE1C9362BF4624050612F2F64D2CA27C7452174ED8F0B56F061703
 +
00000: Start of data
 +
00001/ID: 28
 +
11101/Accessory: 3 items 95 28 92
 +
00011/StartDate: 12/24
 +
00100/EndDate: 12/26
 +
00111/Name: Rudolph
 +
01001/Wildcard: 3
 +
01010/Variant: 2
 +
00000: Start of data
 +
00001/ID: 28
 +
00000: End of data
 +
</pre>
 +
|}
 +
|}
 +
 
 +
There is also a [http://pinataisland.info/vision/readpv.php barcode reader] at this site (that will convert the EAN barcode to its obfuscated hex data).
  
 
==== Generate cards ====
 
==== 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.
+
Work on a card generator has started.  The card generator can currently create named varianted pinata cards, as well as a few other types of cards (e.g., Weather).
 +
 
 +
{| class="collapsible collapsed"
 +
!Sample of generated barcode
 +
|-
 +
|
 +
{|
 +
<pre>
 +
% ./generate_barcode.pl --id=51 --variant=1 --name=Feral --verbose
 +
Encoded data = 00840CEC039CD31C 340A10046998C0A5  Shuffled/Negated = EE2D18643D60061C ED8283EC4391A215  Obfuscated = 995D6E134D17716C 9DE5E49C34F6A562
 +
Card 51 995D6E134D17716C9DE5E49C34F6A562
 +
</pre>
 +
|}
 +
|}
 +
 
 +
There is also [http://pinataisland.info/forum/showthread.php?t=20734 a web-based card generator] at this site, as well as a [[PV Creator for the iPhone and iPod touch]], and a [[PV Creator HD for the iPad]].
  
 
== How you can help ==
 
== How you can help ==
Line 239: Line 316:
 
== See also ==
 
== See also ==
  
 +
*[[Piñata Vision barcode/Decoder|Sample barcode decoder script]]
 
*[[Piñata Vision barcode/List of barcodes|List of barcodes]]
 
*[[Piñata Vision barcode/List of barcodes|List of barcodes]]
 +
 +
[[Category:Pinata Vision barcode]]

Latest revision as of 05:18, 4 December 2012


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

Each barcode row consists of 15 digits, plus a check digit. (The check digit also identifies the specific method used to obfuscate that row's data.)

The Piñata Vision barcode checksum is based on the EAN check digit. Alternating weights of 3 and 1 are used, with the 15th digit having a weight of 3. The weighted values are summed. The check digit is the value which when added to the sum yields a number evenly divisible by 16. (I.e., modulo 16 of the sum plus the check digit will equal 0.)

The barcode data

To conceal the underlying data, the information is obfuscated (on a per-row basis) 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.

Each barcode row decodes to 16x4=64 bits of data. The first 60 bits are encoded data. The last 4 (least significant) bits per row are used for the checksum/obfuscation set.

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 large values as 32- or 16-bit integers. So a use cost value has to be packed to fit into a smaller (fixed) number of bits reserved for the use cost.

Payload type

Although there are many different types of cards, the payload type groups the many similar sets of cards together into a small number of common types for the game to process. The payload type field itself is 5 bits.

The payload type is the key (most significant) field that tells the game exactly what type of data follows. Sub-type values can be found further within the encoded data so the game can distinguish between similar cards such as Appear cutscene and Mate cutscene.

The three different card types seen so far are grouped as follows:

  • Cards which drop an something into the garden:
    • PlaceTag
    • Blackariant
    • GoodVariants
  • Cards which reference a pinata or item:
    • Learn/Perform Primary/Secondary Trick
    • UnlockArt
    • Journal
    • Appear and mate cutscene
    • Other cards likely included within this card type would be House interior
  • Cards which perform an independent action:
    • Sparse callback (e.g., adjust credits balance, change dinosaur color, send in Ruffian)
    • Romance music tracks (official name of card type unknown)
    • Other cards likely included within this card type would be Weather and Timewarp
  • Cards which reskin the trick stick.

The card type example gives a quick visual glance of cards with differing type bits.

Each of these types of cards may share some data that's common to most cards (such as an ID). Other fields might be unique to a that particular card type, such asthe color of dinosaur, or type of weather.

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, is an ID value that identifies the card's item to the game. In short, the barcode says "Place item 586 (a Parrybo home) into the garden (for free)."

All PlaceTag cards are a single payload type, regardless of type of item (e.g., Home, Egg, Fruit, Paving, Prop, ...), and 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 12 bits long. This has been verified by observing that ID bit 11 immediately follows the payload type field for ID bits.

Low-value IDs (0-160?) appear to serve as species IDs, with several similar types of cards utilizing a common species ID (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 a 7-bit field. The magnitude is a 3-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. They have no encoded use cost value at all.

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

The elite neon green reskin card was discovered on April 5, 2011 by FeralKitty.

This project has ended.

Discover the unreleased red sour cards

We have Rare's cards for black variant sours, and have now discovered all the red sour cards.

This project has ended. Read more about it.

Discover the remaining romance music cards

We have a few jukebox track cards that Rare has released. It would be nice to generate barcodes for the remaining species.

This project is not yet underway, but any member is welcome to start working on 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

Now that the barcode data has been deobfuscated, some details have been discovered about the encoded data. Remaining data to be decoded includes:

  • Learning about the remaining payload types (5-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,
  • a "instantly reusable" bit, 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)
  • 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 payloads for ID, use costs, name, accessories, wildcard and variant data, and several other fields for all of the obfuscation sets. Eventually, it would be nice to decode all the data about a card (e.g., accessory items) into a human-readable format.

There is also a barcode reader at this site (that will convert the EAN barcode to its obfuscated hex data).

Generate cards

Work on a card generator has started. The card generator can currently create named varianted pinata cards, as well as a few other types of cards (e.g., Weather).

There is also a web-based card generator at this site, as well as a PV Creator for the iPhone and iPod touch, and a PV Creator HD for the iPad.

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