WoWInterface

WoWInterface (https://www.wowinterface.com/forums/index.php)
-   Legion Beta archived threads (https://www.wowinterface.com/forums/forumdisplay.php?f=177)
-   -   PlayerModel:SetDisplayInfo (https://www.wowinterface.com/forums/showthread.php?t=53428)

semlar 07-03-16 02:53 AM

Quote:

Originally Posted by Resike (Post 316128)
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.

Resike 07-03-16 02:55 AM

Quote:

Originally Posted by Ketho (Post 316126)
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.

telkostrasz 07-03-16 03:18 AM

Hi there, I'm the author of Storyline.

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 !

Resike 07-03-16 03:20 AM

Quote:

Originally Posted by Ketho (Post 316126)
Maybe then it would be possible to get the modelpath from Resike's AllModels.lua if it was put in a library

That could work, however i extracted the data the last time it was avaliable. Every newly added models gonna miss from this list, and it's a pain in the ass to add them without GetModel().

There is a bit newer table from Legion the last time the FileDataComplete.db2 was avaliable [7.0.3 (21737)], just need to combine this 2 tables (I was too busy to do it yet):

https://github.com/Resike/ModelFileDataID

Resike 07-03-16 03:26 AM

Quote:

Originally Posted by telkostrasz (Post 316131)
Hi there, I'm the author of Storyline.

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().

semlar 07-03-16 03:40 AM

Quote:

Originally Posted by telkostrasz (Post 316131)
- 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.

telkostrasz 07-03-16 03:51 AM

Quote:

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

Nope, it just returns 0.

telkostrasz 07-03-16 04:06 AM

Quote:

Originally Posted by semlar (Post 316135)
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? :)

semlar 07-03-16 04:14 AM

Quote:

Originally Posted by telkostrasz (Post 316137)
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 looks like you can actually just call model:GetModelFileID() as a drop-in replacement for GetModel. You'll just have to map out the IDs for the different races.

Some quick numbers..
Lua Code:
  1. ModelFileIDs = {
  2.     female = {
  3.         human = 1000764,
  4.         orc = 949470,
  5.         dwarf = 950080,
  6.         nightelf = 921844,
  7.         undead = 997378,
  8.         tauren = 986648,
  9.         gnome = 940356,
  10.         troll = 1018060,
  11.         goblin = 119369,
  12.         bloodelf = 110258,
  13.         draenei = 1022598,
  14.     },
  15.    
  16.     male = {
  17.         human = 1011653,
  18.         orc = 917116,
  19.         dwarf = 878772,
  20.         nightelf = 974343,
  21.         undead = 959310,
  22.         tauren = 968705,
  23.         gnome = 900914,
  24.         troll = 1022938,
  25.         goblin = 119376,
  26.         bloodelf = 1100087,
  27.         draenei = 1005887,
  28.     }
  29. }

telkostrasz 07-03-16 04:25 AM

Quote:

Originally Posted by semlar (Post 316138)
It looks like you can actually just call model:GetModelFileID() as a drop-in replacement for GetModel. You'll just have to map out the IDs for the different races.

You, sir, just possibly save my day. :)

Do you think that these IDs are persistent between patches (any addition or removal aside of course) or that I would remap ID<->Race at each patch ?

semlar 07-03-16 04:35 AM

Quote:

Originally Posted by telkostrasz (Post 316139)
Do you think that these IDs are persistent between patches (any addition or removal aside of course) or that I would remap ID<->Race at each patch ?

I'm assuming these numbers represent essentially the same thing that the file paths did, and I wouldn't expect them to change between patches unless they change the model.

Ketho 07-03-16 06:58 AM

Quote:

Originally Posted by semlar (Post 316138)
It looks like you can actually just call model:GetModelFileID() as a drop-in replacement for GetModel.


So .. you can't get the displayId from your target, but you can still get the fileId for Simca's FileData.lua? That's nice :)

But when was model:GetModelFileID() added? There is nothing in the recent widget diffs and nothing in the FrameXML either, we have some missing information :S

semlar 07-03-16 07:37 AM

Quote:

Originally Posted by Ketho (Post 316142)
But when was model:GetModelFileID() added?

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.

Some other additional api functions..
Lua Code:
  1. C_ArtifactUI.DoesEquippedArtifactHaveAnyRelicsSlotted
  2. C_ArtifactUI.GetNumObtainedArtifacts
  3. C_ArtifactUI.ShouldSuppressForgeRotation
  4. C_Garrison.GetLooseShipments
  5. C_MapCanvas.GetNumDetailLayers
  6. C_MountJournal.ClearRecentFanfares
  7. C_PetJournal.ClearRecentFanfares
  8. C_Scenario.ShouldShowCriteria
  9. C_TalkingHead.GetConversationsDeferred
  10. C_TalkingHead.IgnoreCurrentTalkingHead
  11. C_TalkingHead.IsCurrentTalkingHeadIgnored
  12. C_TalkingHead.SetConversationsDeferred
  13. C_TaskQuest.GetQuestZoneID
  14. C_TaskQuest.RequestPreloadRewardData
  15. C_TradeSkillUI.IsRecipeSearchInProgress
  16. C_TransmogCollection.ClearNewAppearance
  17. C_TransmogCollection.GetAppearanceCameraIDBySource
  18. C_TransmogCollection.GetLatestAppearance
  19. C_TransmogCollection.IsNewAppearance
  20. AreInvasionsAvailable
  21. EJ_GetInvTypeSortOrder
  22. EJ_IsLootListOutOfDate
  23. GetSpellBookItemTextureFileName
  24. GetSpellTextureFileName
  25. GetTickTime
  26. HasInboxItem
  27. HasSendMailItem
  28. IsInCinematicScene
  29. IsQuestIgnored
  30. IsQuestItemHidden
  31. IsServerControlledBackfill
  32. SortQuestSortTypes
  33. UnignoreQuest

Digital_Utopia 09-08-16 07:26 AM

Quote:

Originally Posted by Simca (Post 315062)
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.

nebula 09-08-16 09:54 AM

Quote:

Originally Posted by Digital_Utopia (Post 318804)
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.

You have a strange understanding of how file systems work.



All times are GMT -6. The time now is 11:40 AM.

vBulletin © 2020, Jelsoft Enterprises Ltd
© 2004 - 2020 MMOUI