Decoding is a little different. We can either interpret the base 64 string as a <b>signed</b> or <b>unsigned</b> number (signed: using 2s complement binary).
</p>
<p>
Things that should be interpreted as <b>signed</b> are:
</p>
<ulclass ="indent">
<li>Skill Points</li>
<li>Any numerical identification value for custom items</li>
</ul>
<p>
Things that should be interpreted as <b>unsigned</b> are:
For items, you can download the item DB here: <ahref ="../clean.json"target ="_blank">clean.json</a>. Each item has an id value that can be put in a map. The NoneItem ID numbers start at 10000 in the canonical order: [helmet, chestplate, leggings, boots, ring 1, ring 2, bracelet, necklace, weapon] (No Weapon has an id of 10008).
For tomes, you can download the tome DB here: <ahref ="../tome_map.json"target ="_blank">tome_map.json</a>. The NoneTome ID numbers start at 61 in the order [no weapon tome, no armor tome, no guild tome] so that we can store tome IDs in 1 Base 64 character.
Version 6 was made to account for the desire to save tomes in a build. As of the last version of this documentation, version 6 is used for encoding whenever there are tomes in the build.
</p>
<divclass ="row section"title ="Example 1: With Tomes">
<number>9</number> items from <code>idMap</code> (<number>3</number> characters each):
<code>06W</code>,
<code>2SH</code>,
<code>0D4</code>,
<code>0Qq</code>,
<code>2SK</code>,
<code>2SL</code>,
<code>02d</code>,
<code>0og</code>,
<code>0Qi</code>
</li>
<li>
<number>5</number> skill point totals (<number>2</number> characters each):
<code>19</code>,
<code>1V</code>,
<code>-E</code>,
<code>0i</code>,
<code>2C</code>
</li>
<li>
<number>1</number> player level (<number>2</number> characters):
<code>1g</code>
</li>
<li>
A <b>variable</b> number of powder "blocks" (<number>5</number> characters which give us <number>6</number> powders per block).
<ulclass ="indent">
<li>For each of the 5 powderable equipment fields [helmet, chestplate, leggings, boots, weapon], we will have the following:</li>
<li><number>1</number> base 64 character that says that we need <number>n</number> blocks for this item.</li>
<li><number>n</number> blocks of <number>5</number> base 64 characters.</li>
<li>
Since there are 4 <code>0</code>s (Base 64 0 = 0 unsigned) in this example, we have no powders on any of the armor piece (no blocks).
</li>
<li>
Then, we have <code>1</code> (Base 64 1 = 1 unsigned). There is 1 block of powders to decode for the weapon item. That is <code>00nZ6</code>.
</li>
<ulclass ="indent">
<li>The unsigned equivalent of <code>00nZ6</code> in binary is 30 <b>binary</b> bits long (omitted). Each section of 5 bits directly corresponds to an powder ID.</li>
</ul>
</ul>
</li>
<li>
<number>7</number> tomes (<number>1</number> character each):
<code>ZU6FCDo</code>
<ulclass ="indent">
<li>The order of tomes listed is [2x weapon tome, 4x armor tome, 1x guild tome].</li>
Version 5 was made to allow for the ability to save custom items. To learn the specifics about custom item encoding, refer to the Custom Items section.
</p>
<p>
As of the last version of this documentation, version 5 is only used for encoding when there are custom items (and no tomes) in the build.
</p>
<divclass ="row section"title ="Example 1: With Custom Item">
<li>Starting in this version, you can substitute in the full hash of a custom item ("CI-[gibberish]") for the 3-character hash of an item pool item, just like for crafted items.</li>
<li>Similar to crafted items, the way we can tell that an item is a custom item is when the 3-character hash of the 'item' is "CI-". No existing item has an item ID of "CI-" in base 64, so we can define a special case check for this "id number".</li>
<li>Further details on parsing and loading this custom item are in the Custom Item section.</li>
</ul>
</li>
<li>
<number>5</number> skill point totals (<number>2</number> characters each):
<code>19</code>,
<code>1V</code>,
<code>-E</code>,
<code>0i</code>,
<code>2C</code>
</li>
<li>
<number>1</number> player level (<number>2</number> characters):
<code>1g</code>
</li>
<li>
A <b>variable</b> number of powder "blocks" (<number>5</number> characters which give us <number>6</number> powders per block).
<ulclass ="indent">
<li>For each of the 5 powderable equipment fields [helmet, chestplate, leggings, boots, weapon], we will have the following:</li>
<li><number>1</number> base 64 character that says that we need <number>n</number> blocks for this item.</li>
<li><number>n</number> blocks of <number>5</number> base 64 characters.</li>
<li>
Since there are 4 <code>0</code>s (Base 64 0 = 0 unsigned) in this example, we have no powders on any of the armor piece (no blocks).
</li>
<li>
Then, we have <code>1</code> (Base 64 1 = 1 unsigned). There is 1 block of powders to decode for the weapon item. That is <code>00nZ6</code>.
</li>
<ulclass ="indent">
<li>The unsigned equivalent of <code>00nZ6</code> in binary is 30 <b>binary</b> bits long (omitted). Each section of 5 bits directly corresponds to an powder ID.</li>
</ul>
</ul>
</li>
</ul>
</div>
<p>
It is possible that version 5 links will have an extra tome section at the end like above (see: Version 6 section). We ignore this in decoding.
Version 4 was made to allow for the ability to save crafted items. To learn the specifics about crafted item encoding, refer to the Crafted Items section.
</p>
<p>
As of the last version of this documentation, version 4 is the default version and is used when there are no custom items or tomes in the build.
</p>
<divclass ="row section"title ="Example 1: No Crafted Items">
<number>9</number> items from <code>idMap</code> (<number>3</number> characters each):
<code>06W</code>,
<code>2SH</code>,
<code>0D4</code>,
<code>0Qq</code>,
<code>2SK</code>,
<code>2SL</code>,
<code>02d</code>,
<code>0og</code>,
<code>0Qi</code>
</li>
<li>
<number>5</number> skill point totals (<number>2</number> characters each):
<code>19</code>,
<code>1V</code>,
<code>-E</code>,
<code>0i</code>,
<code>2C</code>
</li>
<li>
<number>1</number> player level (<number>2</number> characters):
<code>1g</code>
</li>
<li>
A <b>variable</b> number of powder "blocks" (<number>5</number> characters which give us <number>6</number> powders per block).
<ulclass ="indent">
<li>For each of the 5 powderable equipment fields [helmet, chestplate, leggings, boots, weapon], we will have the following:</li>
<li><number>1</number> base 64 character that says that we need <number>n</number> blocks for this item.</li>
<li><number>n</number> blocks of <number>5</number> base 64 characters.</li>
<li>
Since there are 4 <code>0</code>s (Base 64 0 = 0 unsigned) in this example, we have no powders on any of the armor piece (no blocks).
</li>
<li>
Then, we have <code>1</code> (Base 64 1 = 1 unsigned). There is 1 block of powders to decode for the weapon item. That is <code>00nZ6</code>.
</li>
<ulclass ="indent">
<li>The unsigned equivalent of <code>00nZ6</code> in binary is 30 <b>binary</b> bits long (omitted). Each section of 5 bits directly corresponds to an powder ID.</li>
</ul>
</ul>
</li>
</ul>
</div>
<divclass ="row section"title ="Example 2: With Crafted Items">
<number>9</number> items from <code>idMap</code> (<number>3</number> characters each):
<code>06W</code>,
<code>CR-1628i8v8v94948f21</code>,
<code>0D4</code>,
<code>0Qq</code>,
<code>2SK</code>,
<code>2SL</code>,
<code>02d</code>,
<code>0og</code>,
<code>0Qi</code>
<ulclass ="indent">
<li>Starting in this version, you can substitute in the full hash of a crafted item ("CR-[gibberish]") for the 3-character hash of an item pool item.</li>
<li>The way we can tell that an item is a crafted item is when the 3-character hash of the 'item' is "CR-". No existing item has an item ID of "CR-" in base 64, so we can define a special case check for this "id number".</li>
<li>Further details on parsing and loading this custom item are in the Crafted Item section.</li>
</ul>
</li>
<li>
<number>5</number> skill point totals (<number>2</number> characters each):
<code>19</code>,
<code>1V</code>,
<code>-E</code>,
<code>0i</code>,
<code>2C</code>
</li>
<li>
<number>1</number> player level (<number>2</number> characters):
<code>1g</code>
</li>
<li>
A <b>variable</b> number of powder "blocks" (<number>5</number> characters which give us <number>6</number> powders per block).
<ulclass ="indent">
<li>For each of the 5 powderable equipment fields [helmet, chestplate, leggings, boots, weapon], we will have the following:</li>
<li><number>1</number> base 64 character that says that we need <number>n</number> blocks for this item.</li>
<li><number>n</number> blocks of <number>5</number> base 64 characters.</li>
<li>
Since there are 4 <code>0</code>s (Base 64 0 = 0 unsigned) in this example, we have no powders on any of the armor piece (no blocks).
</li>
<li>
Then, we have <code>1</code> (Base 64 1 = 1 unsigned). There is 1 block of powders to decode for the weapon item. That is <code>00nZ6</code>.
</li>
<ulclass ="indent">
<li>The unsigned equivalent of <code>00nZ6</code> in binary is 30 <b>binary</b> bits long (omitted). Each section of 5 bits directly corresponds to an powder ID.</li>
</ul>
</ul>
</li>
</ul>
</div>
<p>
It is possible that version 4 links will have an extra tome string like above (see: Version 6 section) after the powders. You can ignore this in decoding.
<number>9</number> items from <code>idMap</code> (<number>3</number> characters each):
<code>06W</code>,
<code>2SH</code>,
<code>0D4</code>,
<code>0Qq</code>,
<code>2SK</code>,
<code>2SL</code>,
<code>02d</code>,
<code>0og</code>,
<code>0Qi</code>
</li>
<li>
<number>5</number> skill point totals (<number>2</number> characters each):
<code>19</code>,
<code>1V</code>,
<code>-E</code>,
<code>0i</code>,
<code>2C</code>
</li>
<li>
<number>1</number> player level (<number>2</number> characters):
<code>1g</code>
</li>
<li>
A <b>variable</b> number of powder "blocks" (<number>5</number> characters which give us <number>6</number> powders per block).
<ulclass ="indent">
<li>For each of the 5 powderable equipment fields [helmet, chestplate, leggings, boots, weapon], we will have the following:</li>
<li><number>1</number> base 64 character that says that we need <number>n</number> blocks for this item.</li>
<li><number>n</number> blocks of <number>5</number> base 64 characters.</li>
<li>
Since there are 4 <code>0</code>s (Base 64 0 = 0 unsigned) in this example, we have no powders on any of the armor piece (no blocks).
</li>
<li>
Then, we have <code>1</code> (Base 64 1 = 1 unsigned). There is 1 block of powders to decode for the weapon item. That is <code>00nZ6</code>.
</li>
<ulclass ="indent">
<li>The unsigned equivalent of <code>00nZ6</code> in binary is 30 <b>binary</b> bits long (omitted). Each section of 5 bits directly corresponds to an powder ID.</li>
<number>9</number> items from <code>idMap</code> (<number>3</number> characters each):
<code>06W</code>,
<code>2SH</code>,
<code>0D4</code>,
<code>0Qq</code>,
<code>2SK</code>,
<code>2SL</code>,
<code>02d</code>,
<code>0og</code>,
<code>0Qi</code>
</li>
<li>
<number>5</number> skill point totals (<number>2</number> characters each):
<code>19</code>,
<code>1V</code>,
<code>-E</code>,
<code>0i</code>,
<code>2C</code>
</li>
<li>
A <b>variable</b> number of powder "blocks" (<number>5</number> characters which give us <number>6</number> powders per block).
<ulclass ="indent">
<li>For each of the 5 powderable equipment fields [helmet, chestplate, leggings, boots, weapon], we will have the following:</li>
<li><number>1</number> base 64 character that says that we need <number>n</number> blocks for this item.</li>
<li><number>n</number> blocks of <number>5</number> base 64 characters.</li>
<li>
Since there are 4 <code>0</code>s (Base 64 0 = 0 unsigned) in this example, we have no powders on any of the armor piece (no blocks).
</li>
<li>
Then, we have <code>1</code> (Base 64 1 = 1 unsigned). There is 1 block of powders to decode for the weapon item. That is <code>00nZ6</code>.
</li>
<ulclass ="indent">
<li>The unsigned equivalent of <code>00nZ6</code> in binary is 30 <b>binary</b> bits long (omitted). Each section of 5 bits directly corresponds to an powder ID.</li>
Version 1 is the very first encoding version by Wynnbuilder. It allows for saving all equipment (armors, accessories, weapon) and powders put on that equipment.
<number>9</number> items from <code>idMap</code> (<number>3</number> characters each):
<code>06W</code>,
<code>2SH</code>,
<code>0D4</code>,
<code>0Qq</code>,
<code>2SK</code>,
<code>2SL</code>,
<code>02d</code>,
<code>0og</code>,
<code>0Qi</code>
</li>
<li>
A <b>variable</b> number of powder "blocks" (<number>5</number> characters which give us <number>6</number> powders per block).
<ulclass ="indent">
<li>For each of the 5 powderable equipment fields [helmet, chestplate, leggings, boots, weapon], we will have the following:</li>
<li><number>1</number> base 64 character that says that we need <number>n</number> blocks for this item.</li>
<li><number>n</number> blocks of <number>5</number> base 64 characters.</li>
<li>
Since there are 4 <code>0</code>s (Base 64 0 = 0 unsigned) in this example, we have no powders on any of the armor piece (no blocks).
</li>
<li>
Then, we have <code>1</code> (Base 64 1 = 1 unsigned). There is 1 block of powders to decode for the weapon item. That is <code>00nZ6</code>.
</li>
<ulclass ="indent">
<li>The unsigned equivalent of <code>00nZ6</code> in binary is 30 <b>binary</b> bits long (omitted). Each section of 5 bits directly corresponds to an powder ID.</li>
This section is about how to decode crafted items. To view an example of a crafted item in a build, check out <b>Builds > Version 4</b>.
</p>
<p>
Crafted items always start with "CR-" so that they are, as an entire category, distinguishable from item pool items. The ingredients and materials that make up the crafted item are stored in the rest of the "hash".
</p>
<p>
To encode all the info about a crafted item, we need:
</p>
<ulclass ="indent">
<li>Ingredient Data</li>
<li>Recipe Data</li>
<li>Crafting Material Tiers</li>
<li>Attack Speed (for weapons)</li>
</ul>
<p>
Wynnbuilder assigns each ingredient and recipe to a unique ID number.
</p>
<divclass ="row section"title ="ID number specifics">
<p>
For ingredients, you can download the ingredient DB here: <ahref ="../ing_map.json"target ="_blank">ing_map.json</a>. The ID number for No Ingredient is 4000.
</p>
<p>
For recipes, you can download the recipe DB here: <ahref ="../recipe_map.json"target ="_blank">recipe_map.json</a>.
</p>
</div>
<divclass ="row section"title ="Version 1">
<p>
This is the first version of crafted item encoding. Crafted Items are always stored in a constant number of base 64 characters.
This example shows how to parse a crafted item hash.
</p>
<codeclass ="full-width">
CR-1628i8v8v94948f21
</code>
<p>
Crafted item hash format:
</p>
<ulclass ="indent">
<li><number>3</number> characters to denote item type as crafted: <code>CR-</code> (always)</li>
<li><number>1</number> character for encoding version: <code>1</code></li>
<li><number>6</number> ingredient IDs (<number>2</number> Base 64 characters each):
<code>62</code>,
<code>8i</code>,
<code>8v</code>,
<code>8v</code>,
<code>94</code>,
<code>94</code>
</li>
<li><number>2</number> characters for recipe ID: <code>8f</code></li>
<li><number>1</number> character to encode material tiers: <code>2</code>
<ulclass ="indent">
</ul>
</li>
<li><number>1</number> character to encode attack speed: <code>1</code>
<ulclass ="indent">
<li>The integer after doing unsigned decoding from the Base 64 character denotes the index within the following array: [SLOW, NORMAL, FAST]. Base 64 <code>1</code> maps to the unsigned integer <number>1</number>, meaning that the attack speed of this crafted item would be NORMAL if it were a weapon.</li>
<li>Note: although only weapons will have attack speed, we decided to include the character in all crafted item hashes to keep a constant hash length.</li>
</ul>
</li>
</ul>
<p>
You may need to parse a crafted item from a wynnbuilder link with a crafted item.
We can simply take the string after the octothorpe/hash tag (#), tack on "CR-" in front of this string, and arrive at the full hash for the crafted item in question. Decode using the same logic as the previous example.
This section is about how to decode custom items. To view an example of a custom item in a build, check out <b>Builds > Version 5</b>.
</p>
<p>
Custom items always start with "CI-" so that they are, as an entire category, distinguishable from item pool items. The stats and values that make up the custom item are stored in the rest of the "hash".
