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).
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.
|All times are GMT -6. The time now is 11:15 AM.|
vBulletin © 2020, Jelsoft Enterprises Ltd
© 2004 - 2020 MMOUI