How is that gonna help on a totally random model i want to draw ont he screen? Also every model has different camera postions, i just want to get the proper values to manipulate the camera angles further.

I have no idea what you're talking about since I was referring to the reddit post ketho linked to, which was talking about needing to scale the size of quest givers to be more realistic.

But my question is, why does playermodel:GetDisplayInfo() return 0 after running playermodel:SetUnit("target") ?
Is it even possible to get a displayId from a specific unitId?

You can't get the model's path if it's set by SetUnit simply because it's no gonna create a model that exists in the game files, but simply gonna clone the looks of the model the unitid points to, with every armor/weapons equipped and/or apperance changing buffs.

We indeed used GetModel to get a model ID. We don't care if it's a path, a number a hash or whatever, we just need a way to differentiate one model from another when set with SetUnit(unitID).

The reason we do that is because:

- For animations we play several animation sequentially. So we need to know when the previous model animation is finished before launching the next. AFAIK there is no event for this. So we mapped the animation duration based on the modelPath (but again, even a number/hash could work).

- For scaling two models we need to know the races of each. But again, AFAIK there is no way to get an NPC race (UnitRace on a npc does not return anything) ? So we used the modelPath to map it to the race.

So I completely understand that Blizzard want to get away from filePath. But when removing GetModel they didn't brought any replacement allowing to get these hash/fileID instead ?

In short: we need the modelPath/id/hash/whatever to map it to a race, because we need the race for scaling or animation duration. But any idea other is welcome.

We indeed used GetModel to get a model ID. We don't care if it's a path, a number a hash or whatever, we just need a way to differentiate one model from another when set with SetUnit(unitID).

The reason we do that is because:

- For animations we play several animation sequentially. So we need to know when the previous model animation is finished before launching the next. AFAIK there is no event for this. So we mapped the animation duration based on the modelPath (but again, even a number/hash could work).

- For scaling two models we need to know the races of each. But again, AFAIK there is no way to get an NPC race (UnitRace on a npc does not return anything) ? So we used the modelPath to map it to the race.

So I completely understand that Blizzard want to get away from filePath. But when removing GetModel they didn't brought any replacement allowing to get these hash/fileID instead ?

In short: we need the modelPath/id/hash/whatever to map it to a race, because we need the race for scaling or animation duration. But any idea other is welcome.

Hope it helps.

Thanks !

You could try the new api called :GetDisplayInfo() i'm just not sure if it's working on models set with :SetUnit().

- For scaling two models we need to know the races of each. But again, AFAIK there is no way to get an NPC race (UnitRace on a npc does not return anything) ? So we used the modelPath to map it to the race.

If you want to store the scale for specific NPCs you can get their npcID from UnitGUID and use that as an identifier.

It won't be as broad as specifying a scale for a specific model that's shared between different units, but it will be more accurate since models don't determine the size of a unit. For example, blizzard uses the tauren model to create the flaskataur on the PTR, which is considerably larger than a normal tauren.

I didn't realize UnitRace didn't work on NPCs that use a playable race.

If you want to store the scale for specific NPCs you can get their npcID from UnitGUID and use that as an identifier.

It won't be as broad as specifying a scale for a specific model that's shared between different units, but it will be more accurate since models don't determine the size of a unit. For example, blizzard uses the tauren model to create the flaskataur on the PTR, which is considerably larger than a normal tauren.

I didn't realize UnitRace didn't work on NPCs that use a playable race.

Yes, using NPC Ids is a solution we though about, but that means we have to map all npcID from the game to a race? How much IDs does that represents? How could this be easily maintenable?

It was probably added after we complained to a dev on irc about losing GetModel, although I don't recall him mentioning anything about it.

Don't rely on those diffs being 100% accurate; they were generated a couple months ago, and even then they weren't complete. It's missing a few script handlers because there isn't really any way to fetch those when they add new ones, unless they're used in the framexml or you do some reverse engineering on the client.

Specifically, models have an OnModelLoaded script that runs when the model actually shows up, and an OnPanFinished script. Cooldowns have an OnCooldownDone script.

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.

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.

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.