🐛 Augment ID's do not reflect accurately

[N3ckB3ard]

• [x] I have paid attention to this example and will edit again if need be to not break the formatting, or I will be ignored
• [x] I have searched existing issues to see if the issue has already been opened, and I have checked the commit log to see if the issue has been resolved since my server was last updated
• [x] I have read and understood the Contributing Guide

OS / platform the server is running (if known)

Any

Branch affected by issue

base

Steps to reproduce

Adding correct Augment ID's based off client information has not worked for some time. I have looked through the Augment information and can confirm this has been a long living issue. Within the .DAT files we are able to see the ID that corresponds with the augment but using the ID's within our SQL will reflect differently. I am hoping by having this issue open here we can see what information we can collect to implement this to work in a reflective manner. I know in passing this has been looked into but I would like to have a open issue for referencing Augments and for someone looking for a major project.

Client information:

https://github.com/Windower/Resources/blob/master/resources_data/augments.lua https://www.bg-wiki.com/ffxi/Augment_List

Notes:

• Most "Empty" augments will display 1 over the input augment ID (EX: 346->347) and some will display the same input(EX: 302->302)
• Augment 912 will increase the augment ID by the value or "Power" set(EX: Power = 8-"Occ. atk. twice", 11-"Occ. atk. 2-3 times", 12-"Occ. atk. 2-4 times")
• Augment ID = 897 - Enhances Souleater Effect +d% in reference to the client should reflect the ID of 513
• At some point our Augment ID's will shift back into prior numbers and this prevents us from using all available Augments within the client
• Adding Augments to items currently with the Value or "Power" set to 0 will reflect 1(EX: !additem itemId Qty 1(HP+v) 0(v=4) --HP+5)

Expected behavior

[TeoTwawki]

was looking at this earlier today. there are some bytes in the exData of items we haven't implemented that determine the kind of augment data that shoudl be loaded. we only have 1 type implement whioch cuts off the list of evailable IDs far lower than retail.

1st byte is flags, 2nd is sub flags that tell it how to handle the aug. We're currently stopping at 2047 (0x7FF) because the original augments they released were bitpacked, but the list really should reach a 16 bit integer and go all the way to 0xFFxx

~~Not sure if this will post..its big~~ see follow up!

[TeoTwawki]

it cut off the rest..making a gist

[TeoTwawki]

it's so big even the gist page is problematic: https://gist.github.com/TeoTwawki/04d9308774e6b11d119f9a775603764c

augments.md

[TeoTwawki]

I failed to notice this last night when I posted my info dump:

Within the .DAT files we are able to see the ID that corresponds with the augment but using the ID's within our SQL will reflect differently.

There's 2 lists, the dat order and the order the client builds from packet data. we use the latter. the extract I posted is the full list including the once we don't have yet. Dat dumps will never align with the values that have to be fed into the client and if you follow the dat order you will get the wrong thing for 3/4 of them, unless we build some kind of translation table where we have the dat index and the packet ordering matched up.

We're missing 2 bytes of item extra Data to be able to implement the others with the current ordering, plus item data fields in the packets to allow for the socketing for the types that do that.