Quote:
|
Quote:
|
Quote:
You're right that there is no language that can show a model or texture without pointing to the file itself, but those pointers are no longer names - they're namehashes. What used to be "Character\Scourge\Male\ScourgeMale.m2" is now known to the client as E69ABF2F3DAFC6FF, for example. |
Why stop here then? Remove GetName(), GetFont() and so on.
|
It is quite possible for a user to make a library to do this for the game, though. As of present, they are still shipping a file called FileDataComplete.db2 that has a complete listing of the game's internal FileDataIDs to real filenames. Why they are shipping it is a bit of a mystery because the client actually does -not- read the file. Maybe they are trying to help the community? IDK.
It would be a really intense library though... FileDataComplete is 27 MB of strings. |
How can i get access to this file? I can't find it on the casc.
|
I went out and saved what i could can from the live realms:
https://raw.githubusercontent.com/Re...%20(21742).lua Contains every: modelDisplayID - modelPath, up to date. |
When I updated the model viewer valid displayids went up to 73900 I think. GetModel() not returning any values is actually kind of bad. Because up until now you could categorize models by extracting the model path.
|
Quote:
|
Dumb question but has anyone written about this on the official beta forums? If they become aware just how disruptive this is, I am sure they can at least offer alternatives.
|
Quote:
|
Quote:
The latest version (in a Lua format) I just posted here: http://www.mediafire.com/download/kv...j/FileData.lua Not even sure how the game would handle a 49 MB Lua file though, honestly. It could be wildly stripped down by removing development files (FileDataComplete is literally -complete- in that it includes huge swaths of files that are shipped with the client and only exist on developer's PCs and servers) and by eliminating things that aren't textures or models. Edit: Making those changes cuts the file size in half, down to 25 MB. That's a lot, but not enough. I wonder about restricting it further so that it only contains A) Models and B) Textures in Interface\* |
Quote:
|
Quote:
|
Quote:
|
Quote:
So in short, the game can't give you any information it doesn't have, and its extremely unlikely they add extra information just for some addons. Addons will be able to update to the new system eventually, just don't stick to the mentality "its entirely broken", instead think about how you can fix it without relying on Blizzard to fix it for you. We have asked Guill on IRC the other day, and the answer was quite simple: They are trying to use file IDs exclusively in the game. |
Quote:
Also they added GetDisplayInfo() which does exactly the same thing as GetModel() did, reading table indexes from a db file. Too bad GetDisplayInfo is completely useless, since it doesn't return anything that you don't know. |
I have to agree with nevcariel - from what conversation I've had with the devs on the subject over IRC and Twitter, it seems extremely unlikely that they are going to offer us an alternative.
If they readded parsing FileDataComplete to the game, for example, it would be a performance hit. In its most compact uncompressed form (if you split up filenames into 'names' and 'paths' and deduplicate), it is still 27 MB of raw strings. The performance hit would be extremely minor (probably under a second during load time), but they just aren't going to be willing to make -any- performance hit for specific features of optional addons. Memory sniffing is not involved here (like I said, the client doesn't even know what you're looking for - it can't help with this), and if reading CASC data is against the ToS, then so was reading MPQ data (it's the same concept) and everyone here has broken it hundred times over already. :p I'm just trying to help offer productive solutions because I know Blizzard isn't going to do anything about this. |
Quote:
And yes you can sniff this out easily just load the model ingame, check which file gets loaded in the casc, export that file make the casc listfile conversion and shazam you get the model's path. But it's just not really the ideal thing. |
So just to understand, unlike keeping the way resike explains, you now would update models based on targeting and events and store the set model in a variable to be used to maintain a model's 3d portrait/display so long as said model was or is used on say a unit frame/ tooltip or other frame like how the storyline addon displays 3d models?
If that is the case and you use a combination of event triggers then I suppose this would cut down on bloat, resource usage, and potential errors? |
All times are GMT -6. The time now is 08:07 AM. |
vBulletin © 2024, Jelsoft Enterprises Ltd
© 2004 - 2022 MMOUI