Originally Posted by Simca
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.
This is purely a security maneuver - performance has nothing to do with it.
First off DBC/DB2 files are literally databases, designed, and redesigned for performance. WoW doesn't treat these files like the viewers do, where it loads up the entire file to show in a spreadsheet. It loads up the non-string data, and then finds the individual strings it needs to open the file(s), via the string index in the data.
Second, while it's true that the CASC format has no need to keep a list of filenames, filenames are
necessary to load the actual assets. But, since ModelFileData, and
FileDataComplete are no longer stored locally, then it has to get them from the server.
So every time it needs to display a piece of gear - it has to make a request with the TextureFileID, which retrieves the actual filename from FileDataComplete. With Models, since ModelFileData isn't stored locally, it has to make a request with the Model ID, and then, server side, it looks up the ID in ModelFileData, gets the ModelFileID, and then
returns the filename from FileDataComplete. Then uses those files to retrieve the assets from game storage.
So in other words, there's an additional server call, every time it needs to load up a new model/texture, when - performance wise, it would be much more efficient to handle the entire process locally. Both in terms of system, and network performance.
The only feasible reason they would want to do this is, to prevent third-party tools from generating characters, via nothing more than the Blizzard web API, and a copy of the client. I mean, it's still technically possible - it just requires doing things manually. Which is, pretty odd - considering the long history of machinima and other fan-sourced tools.