WynnBuilder Dev

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 starting from Version 8 may look like "?v=[wynn version number]#[version number]_[build hash]". The query section is optional.

All build links older than Version 8 look like "#[version number]_[build hash]".

Version 8 was made to account for an oversight made when designing the tome encoding, and to signal the beginning of versions that support wynn version history. Version 8 and higher links may start with a query indicating the wynn version to use.

Additionally, Version 8 uses 2 characters instead of 1 character to encode the ID of each tome. (The IDs representing NONE tomes does not change.)

Version 7 was made to account for ability trees in wynncraft 2.0. Version 7 introduces a new field at the end of the build hash, for ability tree data. Atree data is compressed using a depth first search algorithm into a binary blob, which is then base-64 encoded and appended to the V6 hash. The binry blob is decompressed by using the corresponding traversal.

The tree structure defining the ability tree can be found in a json file (by default, js/builder/atree_constants_min.json). The file defines connections between the ability tree nodes: Each node has an unordered list of parent nodes, and an ordered list of child nodes.

A reference implementation of the encoding/decoding algorithms can be found in js/builder/build_encode_decode.js. A pseudocode description of the algorithms is given here:


// Encode an ability tree configuration into a binary blob.
// NOTE: this algorithm only works for "connected" (valid) ability trees.
// Its behavior is not well defined otherwise.
//
// Parameters:
//   tree_data:  Object containing ability tree structure.
//   tree_state: Object containing info about which abilities are selected.
function encode(tree_data, tree_state):

    return_vector = BitVector()
    visited = Set()

    function recursive_traverse(head_node):
        for each child of head_node, in order:
            if child is not in visited:
                add child to visited set
                if tree_state.is_active(child):
                    append bit 1 to return_vector
                    recursive_traverse(child)
                else:
                    append bit 0 to return_vector

    recursive_traverse(tree_data.root)
    return return_vector

// Decode a binary blob into an ability tree configuration
//
// Parameters:
//   tree_data:  Object containing ability tree structure.
//   tree_state: Object containing info about which abilities are selected.
//   tree_bitvector: raw binary data, accessed one bit at a time
function decode(tree_data, tree_state, tree_bitvector):

    i = 0
    visited = Set()

    function recursive_traverse(head_node):
        for each child of head_node, in order:
            if child is not in visited:
                add child to visited set
                if tree_bitvector[i]:
                    child.active = True
                    recursive_traverse(child)
                else:
                    child.active = False
                i = i + 1

Version 6 was made to account for the desire to save tomes in a 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.
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.

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.


                            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.

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.

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.

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.

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

This section is about how Wynnbuilder's main builder page processes user input and calculates results. Might be useful if you want to script wynnbuilder or extend it! Or for wynnbuilder developers (internal docs).

Modeling wynnbuilder's internal computations as a directed graph has a few advantages:

Each compute "node" is small(er); easier to debug.
Information flow is specified explicitly (easier to debug).
Easy to build caching for arbitrary computations (only calculate what u need)
Stateless builder! Abstract the entire builder as a chain of function calls
Makes for pretty pictures

TODO

An overview of wynnbuilder's internal structure can be seen here. Arrows indicate flow of information. Colors correspond roughly as follows:

The overall logic flow is as follows:

Item and Powder inputs are parsed. Powders are applied to items.
Items and level information are combined to make a build.
Information from input fields for skill points and edit IDs is collected into an ID bonuses table.
Information about active powder specials, strength boosts, etc. are collected into their own ID tables.
All of the above tables are merged with the build's stats table to produce the "Final" ID bonus table.
Which spell variant (think: major id) to use for each of the 4 spells is computed based on the build.
Spell damage is calculated, using the merged stat table, spell info, and weapon info.

Outputs are computed as follows:

Input box highlights are computed from the items produced by item input box nodes.
Item display is computed from item input boxes.
Build hash/URL is computed from the build, and skillpoint assignment.
Spell damage is displayed based on calculated spell damage results.
Build stats are displayed by builder-stats-display (this same node also displays a bunch of stuff at the bottom of the screen...)

The build sets default skillpoints and edited IDs automatically, whenever a build item/level is updated. This is done using "soft links" by two nodes shown in red (builder-skillpoint-setter and builder-id-setter).

A soft link is where something goes and manually marks nodes dirty and calls their update methods. This is useful for these cases because the skillpoints and editable ID fields usually take their value from user input, but in some cases we want to programatically set them.

For example another soft link (not shown) is used to implement the reset button.