WynnBuilder
+ 
WynnCrafter
+ 
WynnAtlas
+ 
WynnCustom
+ 
WynnGPS
+ 
WynnCrafter
+ 
Swap Icon Style
+ +
diff --git a/css/dev.css b/css/dev.css
new file mode 100644
index 0000000..5f5a2cd
--- /dev/null
+++ b/css/dev.css
@@ -0,0 +1,85 @@
+/* General Styling - used for all elements on /dev/ */
+.row > * {
+ margin-bottom: 0.75rem;
+ margin-left: 0.5rem;
+ padding-left: 0 !important; /*Override grid.scss (bs) */
+}
+
+.row {
+ overflow-wrap: break-word;
+}
+
+.section {
+ margin-top: 1rem;
+ margin-bottom: 1rem;
+ margin-left: 0.5rem;
+ margin-right: 0.5rem;
+ border-left: 3px solid white;
+ border-radius: 0.1rem;
+ /* padding-right: 0rem !important;
+ padding-left: 0rem !important; */
+}
+
+.section-title:hover{
+ font-weight: bold;
+}
+
+.section-title {
+ margin-bottom: 1.5rem;;
+}
+
+ul {
+ /*Needed to override
@@ -220,6 +220,6 @@
docsFns.append(genDocEntry(entry[0], entry[1], null, entry[2]));
}
-
+
- style in sq2bs.css*/
+ list-style-type: circle;
+}
+
+.indent {
+ margin-left: 2rem;
+}
+
+/* Math */
+math, number {
+ font-family: 'CMU Serif', 'Cambria Math', 'Times New Roman', serif;
+}
+
+number {
+ color: rgb(17, 234, 9);
+}
+
+.full-width {
+ width: 100%;
+ text-align: center;
+}
+
+
+
+/* Variable Sizing (specific to dev page) */
+@media screen and (max-width: 600px) {
+ .section-title > * {
+ font-size: 3.5rem;
+ }
+
+ .page-title {
+ font-size: 6rem;
+ }
+}
+
+@media screen and (min-width: 600px) and (max-width: 1400px) {
+ .section-title > * {
+ font-size: 1.25rem;
+ }
+
+ .page-title {
+ font-size: 4rem;
+ }
+}
+
+@media screen and (min-width: 1400px) {
+ .section-title > *{
+ font-size: 1.5rem;
+ }
+
+ .page-title {
+ font-size: 4.5rem;
+ }
+}
\ No newline at end of file
diff --git a/css/sq2bs.css b/css/sq2bs.css
index e0eda75..e349002 100644
--- a/css/sq2bs.css
+++ b/css/sq2bs.css
@@ -437,6 +437,10 @@ input[type=number]::-webkit-outer-spin-button {
/* Make links bold when hovered over */
+.clickable:hover {
+ font-weight: bold;
+}
+
a:hover {
font-weight: bold;
}
diff --git a/dev/index.html b/dev/index.html
new file mode 100644
index 0000000..438a215
--- /dev/null
+++ b/dev/index.html
@@ -0,0 +1,903 @@
+
+
+
+
+
- Skill Points +
- Any numerical identification value for custom items +
- Item ID numbers +
- Tome ID numbers +
- Build Level +
- Ingredient ID numbers +
- Recipe ID numbers +
- Powder numbers +
- The build's items (equipment, tomes) +
- The skill points distributed by the user (and user level) +
- Item powderings +
-
+
9 items fromidMap(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 us6 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 needn blocks for this item.
+ n blocks of5 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 is00nZ6. +
+ - The unsigned equivalent of
00nZ6in 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]. +
+ -
+
9 items fromidMap(3 B64 characters each): +06W, +00m(with the custom itemCI-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 (), in characters. Then the next 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. +
+ - 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
-
+
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 us6 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 needn blocks for this item.
+ n blocks of5 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 is00nZ6. +
+ - The unsigned equivalent of
00nZ6in binary is 30 binary bits long (omitted). Each section of 5 bits directly corresponds to an powder ID.
+
-
+
+ -
+
9 items fromidMap(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 us6 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 needn blocks for this item.
+ n blocks of5 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 is00nZ6. +
+ - The unsigned equivalent of
00nZ6in binary is 30 binary bits long (omitted). Each section of 5 bits directly corresponds to an powder ID.
+
-
+
+ -
+
9 items fromidMap(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 us6 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 needn blocks for this item.
+ n blocks of5 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 is00nZ6. +
+ - The unsigned equivalent of
00nZ6in binary is 30 binary bits long (omitted). Each section of 5 bits directly corresponds to an powder ID.
+
-
+
+ -
+
9 items fromidMap(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 us6 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 needn blocks for this item.
+ n blocks of5 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 is00nZ6. +
+ - The unsigned equivalent of
00nZ6in binary is 30 binary bits long (omitted). Each section of 5 bits directly corresponds to an powder ID.
+
-
+
+ -
+
9 items fromidMap(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 us6 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 needn blocks for this item.
+ n blocks of5 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 is00nZ6. +
+ - The unsigned equivalent of
00nZ6in binary is 30 binary bits long (omitted). Each section of 5 bits directly corresponds to an powder ID.
+
-
+
+ -
+
9 items fromidMap(3 B64 characters each): +06W, +2SH, +0D4, +0Qq, +2SK, +2SL, +02d, +0og, +0Qi+
+ -
+ A variable number of powder "blocks" (
5 B64 characters which give us6 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 needn blocks for this item.
+ n blocks of5 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 is00nZ6. +
+ - The unsigned equivalent of
00nZ6in binary is 30 binary bits long (omitted). Each section of 5 bits directly corresponds to an powder ID.
+
-
+
+ - Ingredient Data +
- Recipe Data +
- Crafting Material Tiers +
- Attack Speed (for weapons) +
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 ) is in the range [
1 ,9 ].
+ - Mat 1's tier is equal to except when this yields 0, in which case it becomes 3. +
- Mat 2's tier is equal to ceil(). +
+ 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
1maps to the unsigned integer1 , 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. +
+ - The integer after doing unsigned decoding from the B64 character denotes the index within the following array: [SLOW, NORMAL, FAST]. B64
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 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, andclassReq, 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.
+
+ - Exception: for the identifications
- 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.
+
+
+ - Rolled IDs (with non-fixed IDs):
+
+ - 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")
+
+ - ID name:
010Gbest%20in%20slot+-
+
- ID name:
01("lore")
+ - ID value length:
0G(16 )
+ - ID value:
best%20in%20slot("best in slot")
+
+ - ID name:
024+-
+
- ID name:
02("tier")
+ - ID value length: None (exception) +
- ID value:
4(tiers[4] = "Fabled")
+
+ - ID name:
040103+-
+
- ID name:
04("slots")
+ - ID value length:
01(1 )
+ - ID sign:
0(positive)
+ - ID value:
3(3 )
+
+ - ID name:
051+-
+
- ID name:
05("type")
+ - ID value length: None (exception) +
- ID value:
1(types[1] = "chestplate")
+
+ - ID name:
0G0302SG+-
+
- ID name:
0G("hp")
+ - ID value length:
03(3 )
+ - ID sign:
0(positive)
+ - ID value:
2SG(10000 )
+
+ - ID name:
0H020Fe+-
+
- ID name:
0H("fDef")
+ - ID value length:
02(2 )
+ - ID sign:
0(positive)
+ - ID value:
Fe(1000 )
+
+ - ID name:
0I020Fe+-
+
- ID name:
0I("wDef")
+ - ID value length:
02(2 )
+ - ID sign:
0(positive)
+ - ID value:
Fe(1000 )
+
+ - ID name:
0J020Fe+-
+
- ID name:
0J("aDef")
+ - ID value length:
02(2 )
+ - ID sign:
0(positive)
+ - ID value:
Fe(1000 )
+
+ - ID name:
0K020Fe+-
+
- ID name:
0K("tDef")
+ - ID value length:
02(2 )
+ - ID sign:
0(positive)
+ - ID value:
Fe(1000 )
+
+ - ID name:
0L020Fe+-
+
- ID name:
0L("eDef")
+ - ID value length:
02(2 )
+ - ID sign:
0(positive)
+ - ID value:
Fe(1000 )
+
+ - ID name:
0M0201Y+-
+
- ID name:
0M("lvl")
+ - ID value length:
02(2 )
+ - ID sign:
0(positive)
+ - ID value:
1Y(98 )
+
+ - ID name:
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 )
+
+ - ID name:
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 )
+
+ - ID name:
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 )
+
+ - ID name:
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 )
+
+ - ID name:
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 )
+
+ - ID name:
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 )
+
+ - ID name:
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 )
+
+ - ID name:
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 )
+
+ - ID name:
+
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/items_adv/items_2_help.html b/items_adv/items_2_help.html
index 161f077..6d35a78 100644
--- a/items_adv/items_2_help.html
+++ b/items_adv/items_2_help.html
@@ -28,9 +28,9 @@
+ 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 [0Kv:
+ , 0,
+ K, and 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: +
+-
+
+ Things that should be interpreted as unsigned are: +
+-
+
+ 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: +
+-
+
+ 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
+ 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: +
+-
+
+
+ + 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: +
+-
+
+ 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: +
+-
+
+
+
+ https://hppeng-wynn.github.io/builder/#4_06WCR-1628i8v8v94948f210D40Qq2SK2SL02d0og0Qi1Q1V-E0l2C1g0000100nZ6zz++++-
+
+ + Build Hash format: +
+-
+
+ 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: +
+-
+
+
+ + Version 2 encoding added the ability to save skill point info. +
+
+
+
+ https://hppeng-wynn.github.io/builder/#2_06W2SH0D40Qq2SK2SL02d0og0Qi191V-E0i2C0000100nZ6
+
+ + Build hash format: +
+-
+
+
+
+ + 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: +
+-
+
+
+ + 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: +
+-
+
+ 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: +
+-
+
+ 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: +
+-
+
+ 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 +
+WynnBuilder
WynnCrafter
WynnAtlas
- WynnCustom
- WynnGPS
- WynnCrafter
+ WynnCustom
+ WynnGPS
+ WynnCrafter
Swap Icon Style