DBC read fails , any changes since 5.0 ?

[iceblockman]

Hi guys

I am trying to read DBC. I used tom_rus's code link below:
My DBC class: Paste2.org - Viewing Paste HmWenKeW
Usage: Paste2.org - Viewing Paste bk83XKZf

the code written time is around patch 5.0.5.

I updated dbc offsets but it gives incorrect info. record struct changed ? any helps.

My goal is to wirte a function(out process) to get spellname given spellid. I searched the forum about it, but still not done. any helps appreciated.

[JuJuBoSc]

Some DBC, including Spell.dbc are now compressed, so you have to figure out how to decompress them, mostly LZ compression according to some strings.

[CatsNimo]

Also record structs are constantly changing - they add and remove columns all the time. Something up to date for 5.0.5 will most likely not work now.

You need code that can derive the number of columns and variable type of each column from the DBC/DB2 itself. More than one existing DBC/DB2 reader supports this approach.

'Fixed' DBC/DB2 readers that use the type of code you've posted (constant structs) cannot adapt to new builds without constant modification, so they're only suited to working for older versions - like if you wanted make a 3.3.7 DBC reader, that would be a fine approach.

[TOM_RUS]

'Fixed' DBC/DB2 readers that use the type of code you've posted (constant structs) cannot adapt to new builds without constant modification, so they're only suited to working for older versions - like if you wanted make a 3.3.7 DBC reader, that would be a fine approach.

You will have to adjust columns no matter what approach you are using: be it struct or or anything.

[Nonowmana]

Good luck with Spell names staying out of process, this is a pain in the ass with all functions involved

[CatsNimo]

You will have to adjust columns no matter what approach you are using: be it struct or or anything.

Not necessarily. There are a few DBCs/DB2s that cannot have their structure derived, yes. One of them, for example, uses packed bytes, so its structure is 4 bytes (ID column) + 1 byte (column 1) + 1 byte (column 2) + 2 blank bytes to meet C alignment standards. That kind of thing is very difficult to predict, so you really need to hardcode it in a struct in order to avoid a ton of exception code.

Also, predicting flag vs int in small DBCs is difficult, so even a very adaptive DBC/DB2 reader can encounter problems there that can benefit from being able to have an optional file that overrides its automatic assignments with fixed structs.

However, many of the more complicated DB files do not change frequently at all. The previous example DBC that uses packed bytes has not changed in format since 1.0.

Edit: A very interesting approach would be a DBC/DB2 reader that read column type information straight from the current game client exe. I don't have the knowledge to build something like that, but in theory it could always be up to date that way.