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 (B64) 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 B64 alphabet.

The Wynnbuilder B64 character table: 

0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz+-
^    ^    ^    ^    ^    ^    ^    ^    ^    ^    ^    ^    ^   
|    |    |    |    |    |    |    |    |    |    |    |    |   
0    5    10   15   20   25   30   35   40   45   50   55   60

The B64 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 B64 characters to encode any of these items in the link! The item of id 1337 corresponds to the B64 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 B64 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 B64 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 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] (No Weapon has an id of 10008).

For tomes, you can download the tome DB here: tome_map.json. 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 B64 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 B64 characters each): 06W, 2SH, 0D4, 0Qq, 2SK, 2SL, 02d, 0og, 0Qi
  • 5 skill point totals (2 B64 characters each): 19, 1V, -E, 0i, 2C
  • 1 player level (2 B64 characters): 1g
  • A variable number of powder "blocks" (5 B64 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 B64 character that says that we need n blocks for this item.
    • n blocks of 5 B64 characters.
    • Since there are 4 0s (B64 0 = 0 unsigned) in this example, we have no powders on any of the armor piece (no blocks).
    • Then, we have 1 (B64 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.

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

Build Hash format:

  • 9 items from idMap (3 B64 characters each): 06W, 00m (with the custom item CI-10000JCustom%20Chestplate0220510G020Fe0M0201a), 0D4, 0Qq, 2SK, 2SL, 02d, 0og, 0Qi
    • Starting in this version, to encode a custom item we substitute in the length of the full hash of a custom item ("CI-[gibberish]") in 3 B64 characters for the item ID, followed by the full hash.
    • When decoding build links of this version or higher, you must check whether or not the 3 characters after the current item are "CI-". If they are, the current 3 characters are the B64 representation of the unsigned length of the custom item hash (n), in characters. Then the next n characters make up the full custom item hash.
    • No existing item has an item ID of "CI-" in B64, 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 B64 characters each): 19, 1V, -E, 0i, 2C
  • 1 player level (2 B64 characters): 1g
  • A variable number of powder "blocks" (5 B64 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 B64 character that says that we need n blocks for this item.
    • n blocks of 5 B64 characters.
    • Since there are 4 0s (B64 0 = 0 unsigned) in this example, we have no powders on any of the armor piece (no blocks).
    • Then, we have 1 (B64 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.

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

Build Hash format:

  • 9 items from idMap (3 N64 characters each): 06W, 2SH, 0D4, 0Qq, 2SK, 2SL, 02d, 0og, 0Qi
  • 5 skill point totals (2 B64 characters each): 19, 1V, -E, 0i, 2C
  • 1 player level (2 B64 characters): 1g
  • A variable number of powder "blocks" (5 B64 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 B64 character that says that we need n blocks for this item.
    • n blocks of 5 B64 characters.
    • Since there are 4 0s (B64 0 = 0 unsigned) in this example, we have no powders on any of the armor piece (no blocks).
    • Then, we have 1 (B64 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 B64 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 B64, 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 B64 characters each): 19, 1V, -E, 0i, 2C
  • 1 player level (2 B64 characters): 1g
  • A variable number of powder "blocks" (5 B64 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 B64 character that says that we need n blocks for this item.
    • n blocks of 5 B64 characters.
    • Since there are 4 0s (B64 0 = 0 unsigned) in this example, we have no powders on any of the armor piece (no blocks).
    • Then, we have 1 (B64 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.

Version 3 encoding added the ability to save build level.

https://hppeng-wynn.github.io/builder/#3_06W2SH0D40Qq2SK2SL02d0og0Qi191V-E0i2C1g0000100nZ6

Build hash format:

  • 9 items from idMap (3 B64 characters each): 06W, 2SH, 0D4, 0Qq, 2SK, 2SL, 02d, 0og, 0Qi
  • 5 skill point totals (2 B64 characters each): 19, 1V, -E, 0i, 2C
  • 1 player level (2 B64 characters): 1g
  • A variable number of powder "blocks" (5 B64 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 B64 character that says that we need n blocks for this item.
    • n blocks of 5 B64 characters.
    • Since there are 4 0s (B64 0 = 0 unsigned) in this example, we have no powders on any of the armor piece (no blocks).
    • Then, we have 1 (B64 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.

Version 2 encoding added the ability to save skill point info.

https://hppeng-wynn.github.io/builder/#2_06W2SH0D40Qq2SK2SL02d0og0Qi191V-E0i2C0000100nZ6

Build hash format:

  • 9 items from idMap (3 B64 characters each): 06W, 2SH, 0D4, 0Qq, 2SK, 2SL, 02d, 0og, 0Qi
  • 5 skill point totals (2 B64 characters each): 19, 1V, -E, 0i, 2C
  • A variable number of powder "blocks" (5 B64 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 B64 character that says that we need n blocks for this item.
    • n blocks of 5 B64 characters.
    • Since there are 4 0s (B64 0 = 0 unsigned) in this example, we have no powders on any of the armor piece (no blocks).
    • Then, we have 1 (B64 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.

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.

https://hppeng-wynn.github.io/builder/#1_06W2SH0D40Qq2SK2SL02d0og0Qi0000100nZ6

Build hash format:

  • 9 items from idMap (3 B64 characters each): 06W, 2SH, 0D4, 0Qq, 2SK, 2SL, 02d, 0og, 0Qi
  • A variable number of powder "blocks" (5 B64 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 B64 character that says that we need n blocks for this item.
    • n blocks of 5 B64 characters.
    • Since there are 4 0s (B64 0 = 0 unsigned) in this example, we have no powders on any of the armor piece (no blocks).
    • Then, we have 1 (B64 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.

This section is about how to decode crafted items. To view an example of a crafted item in a build, check out Builds > Version 4.

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

To encode all the info about a crafted item, we need:

  • Ingredient Data
  • Recipe Data
  • Crafting Material Tiers
  • Attack Speed (for weapons)

Wynnbuilder assigns each ingredient and recipe to a unique ID number.

For ingredients, you can download the ingredient id map here: ing_map.json. The ID number for No Ingredient is 4000.

For recipes, you can download the recipe id map here: recipe_map.json or the recipe DB here: recipes_clean.json.

This is the first version of crafted item encoding. Crafted Items are always stored in a constant number of B64 characters.

This example shows how to parse a crafted item hash.

CR-1628i8v8v94948f21

Crafted item hash format:

  • 3 characters to denote item type as crafted: CR- (always)
  • 1 character for encoding version: 1
  • 6 ingredient IDs (2 B64 characters each): 62, 8i, 8v, 8v, 94, 94
  • 2 B64 characters for recipe ID: 8f
  • 1 character to encode material tiers: 2
    • There are 2 material tiers to decode. The ordering of materials is determined by their order within the corresponding recipe object held in the db.
    • The material tier character (from here on t) is in the range [1, 9].
    • Mat 1's tier is equal to t % 3 except when this yields 0, in which case it becomes 3.
    • Mat 2's tier is equal to ceil( (t - 0.5) / 3).
  • 1 character to encode attack speed: 1
    • The integer after doing unsigned decoding from the B64 character denotes the index within the following array: [SLOW, NORMAL, FAST]. B64 1 maps to the unsigned integer 1, meaning that the attack speed of this crafted item would be NORMAL if it were a weapon.
    • 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.

You may need to parse a crafted item from a wynnbuilder crafter link.

https://hppeng-wynn.github.io/crafter/#1628i8v8v94948f21

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 Builds > Version 5.

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

This is the first version of custom item encoding and decoding.

You will need the full array of item identification saving order and all non-rolled identifications (ex: name). View them below.

ID saving order: ci_save_order = ["name", "lore", "tier", "set", "slots", "type", "material", "drop", "quest", "nDam", "fDam", "wDam", "aDam", "tDam", "eDam", "atkSpd", "hp", "fDef", "wDef", "aDef", "tDef", "eDef", "lvl", "classReq", "strReq", "dexReq", "intReq", "defReq", "agiReq","str", "dex", "int", "agi", "def", "id", "skillpoints", "reqs", "nDam_", "fDam_", "wDam_", "aDam_", "tDam_", "eDam_", "majorIds", "hprPct", "mr", "sdPct", "mdPct", "ls", "ms", "xpb", "lb", "ref", "thorns", "expd", "spd", "atkTier", "poison", "hpBonus", "spRegen", "eSteal", "hprRaw", "sdRaw", "mdRaw", "fDamPct", "wDamPct", "aDamPct", "tDamPct", "eDamPct", "fDefPct", "wDefPct", "aDefPct", "tDefPct", "eDefPct", "spPct1", "spRaw1", "spPct2", "spRaw2", "spPct3", "spRaw3", "spPct4", "spRaw4", "rainbowRaw", "sprint", "sprintReg", "jh", "lq", "gXp", "gSpd","durability","duration","charges"];

Non-rolled string IDs: nonRolled_strings = ["name", "lore", "tier", "set", "type", "material", "drop", "quest", "majorIds", "classReq", "atkSpd", "displayName", "nDam", "fDam", "wDam", "aDam", "tDam", "eDam", "nDam_", "fDam_", "wDam_", "aDam_", "tDam_", "eDam_", "durability", "duration"];

Rolled IDs: rolledIDs = ["hprPct", "mr", "sdPct", "mdPct", "ls", "ms", "xpb", "lb", "ref", "thorns", "expd", "spd", "atkTier", "poison", "hpBonus", "spRegen", "eSteal", "hprRaw", "sdRaw", "mdRaw", "fDamPct", "wDamPct", "aDamPct", "tDamPct", "eDamPct", "fDefPct", "wDefPct", "aDefPct", "tDefPct", "eDefPct", "spPct1", "spRaw1", "spPct2", "spRaw2", "spPct3", "spRaw3", "spPct4", "spRaw4", "rainbowRaw", "sprint", "sprintReg", "jh", "lq", "gXp", "gSpd"];

Non-rolled IDs: nonRolledIDs = ["name", "lore", "displayName", "tier", "set", "slots", "type", "material", "drop", "quest", "restrict", "nDam", "fDam", "wDam", "aDam", "tDam", "eDam", "atkSpd", "hp", "fDef", "wDef", "aDef", "tDef", "eDef", "lvl", "classReq", "strReq", "dexReq", "intReq", "defReq", "agiReq", "str", "dex", "int", "agi", "def", "fixID", "category", "id", "skillpoints", "reqs", "nDam_", "fDam_", "wDam_", "aDam_", "tDam_", "eDam_", "majorIds"];

Tiers: tiers = ["Normal", "Unique", "Rare", "Legendary", "Fabled", "Mythic", "Set", "Crafted"]

Types: types = [ "helmet", "chestplate", "leggings", "boots", "ring", "bracelet", "necklace", "wand", "spear", "bow", "dagger", "relik", "potion", "scroll", "food"];

Attack Speeds: attackSpeeds = ["SUPER_SLOW", "VERY_SLOW", "SLOW", "NORMAL", "FAST", "VERY_FAST", "SUPER_FAST"];

Class Requirements: classes = ["Warrior", "Assassin", "Mage", "Archer", "Shaman"]

Here's an example of a custom item hash.

CI-10000HMeta%20Chestplate010Gbest%20in%20slot0240401030510G0302SG0H020Fe0I020Fe0J020Fe0K020Fe0L020Fe0M0201Y0i0200U220z0204iKK150200U22160200U22170200U22180200U22190200U22

Given a custom item hash, we will in general continue to parse through many identifications and their values until we reach the end of the custom item hash.

Custom item hash format:

  • 1 B64 character denoting encoding/decoding version number: 1
  • 1 character denoting whether or not this item has fixed IDs: 0. (0 for no fixed IDs, 1 for fixed IDs)
  • A series of encoded identifications, each taking a variable number of characters. For every ID, we have to save:
    • 2 B64 characters that represent the identification ID (its index in the CI save order array).
    • 2 B64 characters that represent the length len of the value of the identification.
    • A variable number characters to encode the value of the identification.
    • For string-valued identifications (in the non-rolled strings array), we do not use any encoding for the value. The next len characters of the custom item hash is the raw value of the identification (before substituting space for "%20").
      • Exception: for the identifications tier, type, atkSpd, and classReq, there is no string used. They are encoded as a numerical value representing an index in a pre-defined array (check the Important Arrays section above). They also do not use the earlier-specified 2 characters to store length; instead, they each use only 1 B64 character to store their index in their corresponding arrays.
    • For numerical-valued identifications, encoding depends on the fixed ID value from before.
      • Rolled IDs (with non-fixed IDs):
        • 1 character to denote the sign of the min and max values: 0 for both positive, 1 for negative min and positive max, 2 for positive min and negative max, and 3 for both negative.
        • len B64 characters that represent the unsigned minimum value of the identification.
        • len B64 characters that represent the unsigned maximum value of the identification.
      • Rolled IDs (with fixed IDs) and Non-Rolled IDs:
        • 1 character (binary bit) to denote the sign of the value (0 positive, 1 negative).
        • len B64 characters that represent the unsigned value of the identification.
  • To finish the example, we'll go through all the actual identifications of the provided custom item.
    • "CI-" constant portion
    • Encoding version number: 1
    • Fixed IDs: 0 (non-fixed IDs)
    • 000HMeta%20Chestplate
      • ID name: 00 ("name")
      • ID value length: 0H (17)
      • ID value: Meta%20Chestplate ("Meta Chestplate")
    • 010Gbest%20in%20slot
      • ID name: 01 ("lore")
      • ID value length: 0G (16)
      • ID value: best%20in%20slot ("best in slot")
    • 024
      • ID name: 02 ("tier")
      • ID value length: None (exception)
      • ID value: 4 (tiers[4] = "Fabled")
    • 040103
      • ID name: 04 ("slots")
      • ID value length: 01 (1)
      • ID sign: 0 (positive)
      • ID value: 3 (3)
    • 051
      • ID name: 05 ("type")
      • ID value length: None (exception)
      • ID value: 1 (types[1] = "chestplate")
    • 0G0302SG
      • ID name: 0G ("hp")
      • ID value length: 03 (3)
      • ID sign: 0 (positive)
      • ID value: 2SG (10000)
    • 0H020Fe
      • ID name: 0H ("fDef")
      • ID value length: 02 (2)
      • ID sign: 0 (positive)
      • ID value: Fe (1000)
    • 0I020Fe
      • ID name: 0I ("wDef")
      • ID value length: 02 (2)
      • ID sign: 0 (positive)
      • ID value: Fe (1000)
    • 0J020Fe
      • ID name: 0J ("aDef")
      • ID value length: 02 (2)
      • ID sign: 0 (positive)
      • ID value: Fe (1000)
    • 0K020Fe
      • ID name: 0K ("tDef")
      • ID value length: 02 (2)
      • ID sign: 0 (positive)
      • ID value: Fe (1000)
    • 0L020Fe
      • ID name: 0L ("eDef")
      • ID value length: 02 (2)
      • ID sign: 0 (positive)
      • ID value: Fe (1000)
    • 0M0201Y
      • ID name: 0M ("lvl")
      • ID value length: 02 (2)
      • ID sign: 0 (positive)
      • ID value: 1Y (98)
    • 0i0200U22
      • ID name: 0i ("hprPct")
      • ID value length: 02 (2)
      • ID sign: 0 (both positive)
      • ID value minimum: 0U (30)
      • ID value maximum: 22 (130)
    • 0z0204iKK
      • ID name: 0z ("hprRaw")
      • ID value length: 02 (2)
      • ID sign: 0 (both positive)
      • ID value minimum: 4i (300)
      • ID value maximum: KK (1300)
    • 0z0204iKK
      • ID name: 0z ("hprRaw")
      • ID value length: 02 (2)
      • ID sign: 0 (both positive)
      • ID value minimum: 4i (300)
      • ID value maximum: KK (1300)
    • 150200U22
      • ID name: 15 ("fDefPct")
      • ID value length: 02 (2)
      • ID sign: 0 (both positive)
      • ID value minimum: 0U (30)
      • ID value maximum: 22 (130)
    • 160200U22
      • ID name: 16 ("wDefPct")
      • ID value length: 02 (2)
      • ID sign: 0 (both positive)
      • ID value minimum: 0U (30)
      • ID value maximum: 22 (130)
    • 170200U22
      • ID name: 17 ("aDefPct")
      • ID value length: 02 (2)
      • ID sign: 0 (both positive)
      • ID value minimum: 0U (30)
      • ID value maximum: 22 (130)
    • 180200U22
      • ID name: 18 ("tDefPct")
      • ID value length: 02 (2)
      • ID sign: 0 (both positive)
      • ID value minimum: 0U (30)
      • ID value maximum: 22 (130)
    • 190200U22
      • ID name: 19 ("eDefPct")
      • ID value length: 02 (2)
      • ID sign: 0 (both positive)
      • ID value minimum: 0U (30)
      • ID value maximum: 22 (130)

You may need to parse a custom item from a Wynnbuilder customizer link.

hppeng-wynn.github.io/custom/#10000HMeta%20Chestplate010Gbest%20in%20slot0240401030510G0302SG0H020Fe0I020Fe0J020Fe0K020Fe0L020Fe0M0201Y0i0200U220z0204iKK150200U22160200U22170200U22180200U22190200U22

Similar to crafted items, the part of the link after the "#" is the rest of the custom item after the "CI-" constant portion. You may need to convert all "%20" to spaces manually.

Details on reading custom items in build links are provided in the Decoding WB links > Builds section.

Last updated: 30 May 2022