File name from file ID
 

Hoping I missed this somewhere...

Did anyone ever figure out how to get the file name/path from the new file IDs?

I'm trying to update LibAdvancedIconSelector for one of my addons. This library gives you a window with all macro/item icons that is searchable. (ie, want to see all the icons of shields? - they probably have the word shield in their file name)

It uses GetMacroIcons() and GetMacroItemIcons() to compile its filename list. However these functions now return the IDs instead of the names. Can't search 132398 for "shield". :rolleyes:

If this hasn't been figured out, does anyone more creative than me at the moment (obviously) have any ideas? :o


/edit: oh, and I found that texture:SetToFileData(index) has been removed, since you can just use :SetTexture(index) now.

You did ;)
Simca extracted the FileDataIDs from the DBFilesClient, if that helps

(Edit 21/7) Foxlit also has the (textures) in ArtTextureID.lua
(Edit 25/7) Looks like Bear in Mind / LibAdvancedIconSelector is updated with the Interface/ICONS FileDataIDs



I experienced the same problem when I tried to see if I could add a search bar to LargerMacroIconSelection
The FileDataIDs for the 14600+ macro icons could be added to LibAdvancedIconSelector or maybe a new library. It would add around 1 MB to the file



That change was totally throwing me off for a while x)

But the API is getting less and less consistent :( *looks at the new model:GetModelFileID*

Thanks, Ketho! I knew I had seen something a while ago, but had totally forgotten where and couldn't find it. So I just doubted its existence. ;)

TOM_RUS has a FileDataLib posted on CurseForge now that is a better version of the paste I made earlier (he also compacts the data by splitting filenames and filepaths into different arrays and then combines them at runtime): http://wow.curseforge.com/addons/filedatalib/

I believe it can still be greatly improved as there are some missing features that are desirable (such as a reverse lookup) and it is also bloated because it contains nearly everything (I poked TOM about removing many file types that the API literally can't reference, though, which should help).

Yes, this is a problem because there are actually 3 types of FileDataID now. Here's a basic overview.

FileDataID

• The primary means of referencing any file in modern WoW
• Implemented in CASC's 'root' file alongside nameHash as the only ways to lookup a file

ModelFileDataID

• Used internally to reference model files in almost all cases (spell visuals seem to go directly to FileDataID in a few places because being consistent is hard)
• Used to bunch many different FileDataIDs together who have the same purpose but slightly different characteristics. For example, a helmet item will reference 1 ModelFileDataID, which in turn will resolve into a different FileDataID for every race/gender combination. The characteristics supported in this grouping process are: RaceID, SexID, SpecID, and 'Order' (0 = left shoulder, 1 = right shoulder, -1 = everything else).
• Implemented by ComponentModelFileData.db2 (details the characteristics) and ModelFileData.db2 (groups the FileDataIDs by ModelFileDataID).

TextureFileDataID

• Used internally to reference texture files in almost all cases (UI rendering seems to go directly to FileDataID in a few places because being consistent is hard)
• Used to bunch many different FileDataIDs together who have the same purpose but slightly different characteristics. For example, a chestpiece item will reference several TextureFileDataIDs, which in turn will resolve into a different FileDataID for each gender (chests on female characters have to use different textures). The three characteristics supported in this grouping process are: RaceID, SexID, and SpecID.
• Implemented by ComponentTextureFileData.db2 (details the characteristics) and TextureFileData.db2 (groups the FileDataIDs by TextureFileDataID).

The API is inconsistent in both its parameters and returns. Part of the blame lies in the inconsistencies of the internal data structures (as I briefly noted in the summaries above), but this is then compounded by more inconsistencies on the API side. For example, SetTexture only takes FileDataIDs and filenames but not TextureFileDataIDs, but model:GetModelFileID only returns ModelFileDataIDs (also, they shorten the real name to 'ModelFileID', which bothers me).

Looking back at this post, this is probably valuable information for the wiki somewhere too.