Calculate size of Localization data in DBC/DB2

How would I go about calculating the size of the localization data in the dbc/db2? So far I can see something like this:

header = 48 bytes.

localization_data = calculated size

record_data = record count * (field count*4)

string_data = the rest of the file.

To get the offset for record_data down, I need to size of the localization data block size. Is there a localization block

in all dbc/db2?

There is no such thing as localization data inside db2 files - they only have strings in one locale (multilocale installations simply have multiple files)

The same applies to 6.x dbc files

Legacy 3.3.5 handled it differently - each string field was actually an array of 16 strings with space for locale

Thanks Shauren! Everyone’s help is very much appreciated. I was trying to calculate the offset from the beginning of the db2 file (like item-sparse.db2) to the beginning of the actual data records. I noticed between the header “block” and the data record “block” there was 804,186 bytes of data that I didn’t really think I needed (I just need the record data and strings). I incorrectly assumed this was localization data block. I was thinking this would be different for each dbc/db2 and I would need an algorithm for each. Is this area between the header and records based off the record count themselves? Or is it something different?

I kinda did it in reverse for now. fileSIZE - textBLOCKSIZE - recordBLOCKSIZE → beginning of the record data.

Why didn’t you just do it the way TC does? https://github.com/TrinityCore/TrinityCore/blob/6.x/src/server/shared/DataStores/DB2StorageLoader.cpp#L161

Including ready made libraries and keeping new/existing development more efficient and “focused” is definitely something I value highly, but C++ isn’t something I’ve learned just yet, though it’s definitely on my list (I know I’ll need this to help out with TC projects). Reading C++ source, for now, is a bit tricky for me and adds an additional project overhead start time wise. For now, I’ll have to stick with the cludgier VB (which, from what I can tell, has less functionality than C++) for the bulk of the designing then convert everything over when I have a better understanding of C++.

I’d really love to see a “real time” editor, in a “creation kit” fashion, with a “Generate” button to create the SQL update code for the object being created/updated. For now I’m sticking with a text based HTML style format, until I have more time and experience with the database structures and 3D rendering. It’s more time consuming, but the framework is pretty much done. I’ll be fairly tied up this week and somewhat into next, so I’ll spend most of what time I can cleaning up the existing code and making it more efficient, then start adding more options. It usually takes me a bit to fully research database structures, which fields link to and contain what.

I’ve been working mostly with the 6.x database, with the data for the starting zones, though I try to design things that work for both.

Quick note: It was kind of a “qad” thing where I read about the structure of the DBC/DB2 files, used HxD to look at the hex data and verify the values, then do a quick calc to get that part of the project off the to do list.

My point was to simply look at what our code does instead of just taking it (in case you use a different language) - the 5 lines i linked were that “magic” block that you needed its size to get to data part

Worked great. Thanks!

Good resources for any kind of client files:

https://wowdev.wiki/DBC

https://wowdev.wiki/DB2

Thanks Magnuss! I’d checked there to get the “structure” size for the header, and could “fudge” the offset to the data block (after some HxD scraping), but really didn’t like that idea. After taking a look at the existing TC code I was able to see how the size is “calculated”. This way I can have a unified sub/function to open/extract the record and string portions from any DBC/DB2 (that I have a coded handler for).