Wynnbuilder Developer Page
Welcome to the Wynnbuilder page for developers! Here we provide documentation and specifications for our website. Read through these sections to learn more about how WynnBuilder works!

This section is about the encoding schemes Wynnbuilder uses for its various saveable items (builds, crafted items, and custom items).

We use a Base 64 encode/decode system in most shareable links. It would be quite clunky to put a bunch of numbers (the data we save and read) into one link. To save some space, we compress the base 10 numerical alphabet into a custom base 64 alphabet.

The Wynnbuilder Base 64 character table:

0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz+-

The Base 64 encoding of a number (in the 0 to 63 range) is equal to the character at the index within the above string.

For example, if we have a set of items with id numbers in the range [0, 10000], we need at most 3 base 64 characters to encode any of these items in the link! The item of id 1337 corresponds to the Base64 hash 0Kv: 1337 = 0 * 4096 + 20 * 64 + 57, 0 maps to 0, 20 maps to K, and 57 maps to v.

Decoding is a little different. We can either interpret the base 64 string as a signed or unsigned number (signed: using 2s complement binary).

Things that should be interpreted as signed are:

  • Skill Points
  • Any numerical identification value for custom items

Things that should be interpreted as unsigned are:

  • Item ID numbers
  • Tome ID numbers
  • Build Level
  • Ingredient ID numbers
  • Recipe ID numbers
  • Powder numbers

Now that we understand the base 64 system, we can move on to the way builds, crafted items, and custom items are stored in links.

First, what do we need in order to encode an entire build?

Wynnbuilder mainly runs calculations for damages and defense. Therefore, we need:

  • The build's items (equipment, tomes)
  • The skill points distributed by the user (and user level)
  • Item powderings

Wynnbuilder assigns each item in the Wynncraft item pool to a unique ID number. For example, the bracelet Atlas has an id number of 167. We can then store all of a build's item pool items in a link with the items' id numbers. A similar idea is used for skill points and powders. However, we know how many different skills there are already (5), so we can encode the user's assignment of skill points in 5 numbers. With powders, it's a little different. There are 31 "states" of powder: 1 for no powder and then 5 elements with 6 tiers of powder for each element. We will know how many available powder slots we have based on our equipment. We can then put all of these numbers in a specific order (after running Base 64 encoding) to get our build link.

For items, you can download the item DB here: clean.json. 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].

For tomes, you can download the tome DB here: tomes.json. Each tome has a tomeID value that can be put in a map. 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.

For powders: id numbers 1 through 30 map to Earth I, Earth II, ..., Earth VI, etc. in the order Earth, Thunder, Water, Fire, Air. 0 is the id number for no powder.

All build links will end in "#[version number]_[build hash]".

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.

https://hppeng-wynn.github.io/builder/#6_06W2SH0D40Qq2SK2SL02d0og0Qi191V-E0i2C1g0000100nZ6ZU6FCDo

Build hash format:

  • 9 items from idMap (3 characters each): 06W, 2SH, 0D4, 0Qq, 2SK, 2SL, 02d, 0og, 0Qi
  • 5 skill point totals (2 characters each): 19, 1V, -E, 0i, 2C
  • 1 player level (2 characters): 1g
  • A variable number of powder "blocks" (5 characters which give us 6 powders per block).
    • For each of the 5 powderable equipment fields [helmet, chestplate, leggings, boots, weapon], we will have the following:
    • 1 base 64 character that says that we need n blocks for this item.
    • n blocks of 5 base 64 characters.
    • Since there are 4 0s (Base 64 0 = 0 unsigned) in this example, we have no powders on any of the armor piece (no blocks).
    • Then, we have 1 (Base 64 1 = 1 unsigned). There is 1 block of powders to decode for the weapon item. That is 00nZ6.
      • The unsigned equivalent of 00nZ6 in binary is 30 binary bits long (omitted). Each section of 5 bits directly corresponds to an powder ID.
  • 7 tomes (1 character each): ZU6FCDo
    • The order of tomes listed is [2x weapon tome, 4x armor tome, 1x guild tome].

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.

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.

http://hppeng-wynn.github.io/builder/#5_06W00mCI-10000JCustom%20Chestplate0220510G020Fe0M0201a0D40Qq2SK2SL02d0og0Qi191V-E0i2C1g0000100nZ6zz++++-

Build Hash format:

  • 9 items from idMap (3 characters each): 06W, CI-10000JCustom%20Chestplate0220510G020Fe0M0201a, 0D4, 0Qq, 2SK, 2SL, 02d, 0og, 0Qi
    • 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.
    • 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".
    • Further details on parsing and loading this custom item are in the Custom Item section.
  • 5 skill point totals (2 characters each): 19, 1V, -E, 0i, 2C
  • 1 player level (2 characters): 1g
  • A variable number of powder "blocks" (5 characters which give us 6 powders per block).
    • For each of the 5 powderable equipment fields [helmet, chestplate, leggings, boots, weapon], we will have the following:
    • 1 base 64 character that says that we need n blocks for this item.
    • n blocks of 5 base 64 characters.
    • Since there are 4 0s (Base 64 0 = 0 unsigned) in this example, we have no powders on any of the armor piece (no blocks).
    • Then, we have 1 (Base 64 1 = 1 unsigned). There is 1 block of powders to decode for the weapon item. That is 00nZ6.
      • The unsigned equivalent of 00nZ6 in binary is 30 binary bits long (omitted). Each section of 5 bits directly corresponds to an powder ID.

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.

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.

http://hppeng-wynn.github.io/builder/#4_06W2SH0D40Qq2SK2SL02d0og0Qi191V-E0i2C1g0000100nZ6zz++++-

Build Hash format:

  • 9 items from idMap (3 characters each): 06W, 2SH, 0D4, 0Qq, 2SK, 2SL, 02d, 0og, 0Qi
  • 5 skill point totals (2 characters each): 19, 1V, -E, 0i, 2C
  • 1 player level (2 characters): 1g
  • A variable number of powder "blocks" (5 characters which give us 6 powders per block).
    • For each of the 5 powderable equipment fields [helmet, chestplate, leggings, boots, weapon], we will have the following:
    • 1 base 64 character that says that we need n blocks for this item.
    • n blocks of 5 base 64 characters.
    • Since there are 4 0s (Base 64 0 = 0 unsigned) in this example, we have no powders on any of the armor piece (no blocks).
    • Then, we have 1 (Base 64 1 = 1 unsigned). There is 1 block of powders to decode for the weapon item. That is 00nZ6.
      • The unsigned equivalent of 00nZ6 in binary is 30 binary bits long (omitted). Each section of 5 bits directly corresponds to an powder ID.
https://hppeng-wynn.github.io/builder/#4_06WCR-1628i8v8v94948f210D40Qq2SK2SL02d0og0Qi1Q1V-E0l2C1g0000100nZ6zz++++-

Build Hash format:

  • 9 items from idMap (3 characters each): 06W, CR-1628i8v8v94948f21, 0D4, 0Qq, 2SK, 2SL, 02d, 0og, 0Qi
    • 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.
    • 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".
    • Further details on parsing and loading this custom item are in the Crafted Item section.
  • 5 skill point totals (2 characters each): 19, 1V, -E, 0i, 2C
  • 1 player level (2 characters): 1g
  • A variable number of powder "blocks" (5 characters which give us 6 powders per block).
    • For each of the 5 powderable equipment fields [helmet, chestplate, leggings, boots, weapon], we will have the following:
    • 1 base 64 character that says that we need n blocks for this item.
    • n blocks of 5 base 64 characters.
    • Since there are 4 0s (Base 64 0 = 0 unsigned) in this example, we have no powders on any of the armor piece (no blocks).
    • Then, we have 1 (Base 64 1 = 1 unsigned). There is 1 block of powders to decode for the weapon item. That is 00nZ6.
      • The unsigned equivalent of 00nZ6 in binary is 30 binary bits long (omitted). Each section of 5 bits directly corresponds to an powder ID.

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.

http://localhost:8000/builder/#5_06W02hCI-10000HMeta%20Chestplate010Gbest%20in%20slot0240401030510G0302SG0H020Fe0I020Fe0J020Fe0K020Fe0L020Fe0M0201Y0i0200U220z0204iKK150200U22160200U22170200U22180200U22190200U220D40Qq2SK2SL02d0og0Qi191V-E0i2C1g0000100nZ6zz++++-

Last updated: 25 May 2022