Jump to content

Legion Modding and Filedata, possible ?

By Rangorn
in Miscellaneous

Recommended Posts

Hey, since few days, TrinityCore is able to handle Legion (7.0.3)

I will probably switch to Legion for modding (retroporting is bad, really.) but there are some problems.

Since WoD, every string path / name (world/generic/doodad/tree/whatevergob01.m2) are located in the FileDataComplete dbc, it store all the pathname of files from the game, dbc like gameobjectdisplayinfo, charsections don't have a string column anymore, but a integer column who point directly to FileData.

Since 7.0.1.21737 Legion Build, this file is gone, and i don't know how the executable made the link between the filedata_id and the pathname.

Some people seems to know, but it wasn't really clear for me, explanations will be appreciated about this (i mean, clear informations, not an agressive sentance with only 5 words and c++ struct random dropping)

 

So even if we find where the filedata_id <=> string system is located, can we edit it for adding new path and new ids ?

 

 

 

Link to comment
Share on other sites

i'm back (last time i was on the irc, nobody was talking so... maybe later)

 

On 22/07/2016 at 9:48 AM, wungasaurus said:

There is no filedata_id <=> string system, thus you can't edit it.

 

Shauren, the main TC dev told me :

"No. No mapping between FileDataId and FileName exists anymore.

You can still open a file by name (if you know it). Since TC does not need to know the name there are no plans to create such table"

 

 

But, how the cascexplorer, with a listfile, can find the good name/patch for the files ? and why there are DBFilesClient/XXX.db2 string referenced in the wow.exe ?

Still confusing for me.

 

 

 

Link to comment
Share on other sites

Ok do you have more informations for the hashing method ?

Without Listfile, the map.db2 unk file name is 76A46B277AE9D377_1349477, i'm sure the 1349477 is the file data id, and the 16 characters before are hashed.

When i convert theses string to md5, i got this :

dbfilesclient/map.db2 58dd9bcf7aace121ca11336a7cf3f7ae
DBFILESCLIENT/map.db2 a05c28748296ac0ef2362e9c658a0ebd
DBFILESCLIENT/MAP.db2 7cd8f374c7c9f762d78b4897f6d16dcf
DBFILESCLIENT/MAP.DB2 9cc2ef50d67bb7ca1cfa797e2b151844

I'm wrong i know, btw, how the hashing work ? It is the jenkins96 hash ?

Link to comment
Share on other sites

Thanks man, finally manage to do it !

I've made a program in java (poorly made, but i'm fucking lazy when i program)

https://ghostbin.com/paste/5b4kj

 

 

EDIT :  CascExplorer have an option "Extract CASC System Files" and i can get the root =)

So, now i have the root file ! Too bad there is not information about the struct on the wiki, i think i have to analyse source code of Trinity / CASC Explorer / LISTROOT

Link to comment
Share on other sites

It's not about using another program, just CMake and Visual studio pissing me off, and i don't want to waste time trying to fix problems.

 

BTW, i have modified CascExplorer Code and i start to understand the Root structure, not really difficult finally.

Link to comment
Share on other sites

Ok, now i have my own wowRootParser, and gave me the full list of filedataid<=>Hashname

 

Btw, telling me that filedata is gone, now all the filedata ids are referenced in the root file (extractable from CascEditor, in the menu) and hash values are just the filename hashed with the Jenkins96/lookup3/hashlittle2 method, in only one sentance to my first question, it would have been better.

Srsly, it's not a puzzle game where i got a new clue after a resoluted enigma.

Link to comment
Share on other sites

×
×
  • Create New...