[Legion] WDB5 format

[schlumpf]

According to the c and c++ standards the padding is implicit by just writing the struct. I think that if we want to mentio it, it should be via ((_aligned_(32))) pragma or alike. It isn't table specific but just a language feature. I realize it can lead to confusion.

[Rangorn]

Ok i'm done with WDB5

The furry already made a program for parsing All the files into csv format
https://github.com/Arctium-Emulation/Tools

I will maybe only contribute to the wiki by referencing structure + column name.

[Rangorn]

[deleted]

[schlumpf]

That change happened between cata and wod, to be exact

[Uthil]

Build 21531 has WDB5, im looking for an editor/viewer or something similar. All my search end up to find up too wdb2, thats already outdated. It will possible to read WDB5 from now on ?? Since blizz tries to complex things more and more as heading to close legion.

[Rangorn]

[deleted]

[schlumpf]

That comes from how they count "columns". It was changed from four fields to an array of four before/in wod. Counting an array as just one column changed in wdb6. So yes, it now shows that it is an array, but the struct used was using an array before

[Steff]

They started earlierwith this grouping. CharRace for example in wod is also in this form.

[Rangorn]

Yeah, but i'm talking about the header

[Rangorn]

[deleted]

[Simca]

Yeah, basically old school DBC column guessing strategy.

I use a priority-based system, like:
1. If every value in the column is 0, it's an integer.
2. If every value in the column exists in our string position map, it's a string.
3. If every value in the column where it is not 0 has the exponent bits for floats set to a number greater than ~120, it's a float.
4. Else, it's an integer.

A couple notes for WDB5: string and float fields still -must- be 4 bytes. So if the field is less than 4 bytes, it is automatically an integer.

Also, there are going to be a lot of problems with signed and unsigned integers if you autodetect like this. Foreign keys are generally unsigned and it sometimes makes a big difference. Other values are generally signed, and it sometimes makes a big difference. You might be able to write some form of autodetection for signed vs unsigned (or take it from somewhere else) but it is going to be annoyingly complicated.

Lastly, I recommend against a dedicated flags column type. At the end of the day, displaying the numbers as 0x(some hex value) doesn't actually make flags significantly more clear or useful (imo), so it's best to just parse flags you want later, after converting to CSV or some other form.

[Rangorn]

[deleted]

[Steff]

I think it is great if your tool supports gussing but you should also implement the posibillity to rework your gusses.
Just save the structure in a xml.csv whatever format and let the uset change the names of columns and the types.

[Rangorn]

[deleted]

[schlumpf]

texturefiledata or something