6.0 UI Add-On Changes - Updated Aug 4

UI and Macro
08/01/2014 12:29 PMPosted by Macdeth
You can't really disassembled/reverse engineer how the api calls are now, changes, new ones etc..


Actually, that's exactly what they do.
You can run "ExportInterfaceFiles code" or "ExportInterfaceFiles art" from the command console in the login screen to get the Blizzard lua/xml files or the Blizzard textures respectively. From there it's just a simple diff from previous extracted versions.


Thanks.

However, unlike why we really should have to figure out quests mechanics, boss fights, and such by ourselves there is simply no reason why Blizzard shouldn't publish that the api calls are and their basic parameter documentation.

In fact, it WILL cause significant impact on Blizzard staff resources due to incorrect guessing of how some api calls work. How many times do we see questions posted in Tech Support that smell like malfunctioning addons? Yes, I am sure bad coding of the Addon itself is likely at fault many times, however why add to the number of problems posted? They MUST have an internal set of documentation on every single API anyway.

There is simply zero benefit to the game/lore/experience when they force addon creators to guess/reverse engineer api calls/parameters/etc info.
After digging into C_TimerAugment.lua

I'm pretty dissapointed. The only actual C function is C_Timer.After.
If I understand their code correctly. Their timer code just calls C_Timer.After over and over again to make a timer. I don't see how this is better than using an animation group which is written in C, that will call your function over and over.

The only good thing C_Timer.After is good for is adding a waittime for your animationgroup timer to start at.
08/03/2014 04:42 PMPosted by Galvin
After digging into C_TimerAugment.lua

I'm pretty dissapointed. The only actual C function is C_Timer.After.
If I understand their code correctly. Their timer code just calls C_Timer.After over and over again to make a timer. I don't see how this is better than using an animation group which is written in C, that will call your function over and over.

The only good thing C_Timer.After is good for is adding a waittime for your animationgroup timer to start at.


Do animation groups fire any more frequently than OnUpdate though? I'm betting that the resolution of all these methods is still dependent on the frame rate in the end.
Don't think more frequently, but I imagine the accuracy of using animationgroups for timers is better than an onupdate function and less cpu usage. Onupdate being lua vs C code animationgroups.

Thing is blizzard is adding overhead with the way they're doing it. The ticker code is doing one function call for C_Timer.After, then another function call for the callback. Where as if you did an animation group it would just be one function call for your callback.
08/03/2014 11:34 PMPosted by Galvin
Don't think more frequently, but I imagine the accuracy of using animationgroups for timers is better than an onupdate function and less cpu usage. Onupdate being lua vs C code animationgroups.

Thing is blizzard is adding overhead with the way they're doing it. The ticker code is doing one function call for C_Timer.After, then another function call for the callback. Where as if you did an animation group it would just be one function call for your callback.

Hello Galvin, the UI team has the following to say over concerns with regards to overhead and efficiency.

In most cases, initiating a second C_Timer is still going to be cheaper than using an Animation or OnUpdate. The issue here is that both Animation and OnUpdate calls have overhead that applies every frame while they are active. For OnUpdate, the overhead lies in the extra function call to Lua. For Animations, we’re doing work C-side that allows us to support smoothing, parallel animations, and animation propagation. In contrast, the new C_Timer system uses a standard heap implementation. It’s only doing work when the timer is created or destroyed (and even then, that work is fairly minimal).

The one case where you’re better off not using the new C_Timer system is when you have a ticker with a very short period – something that’s going to fire every couple frames. For example, you have a ticker you want to fire every 0.05 seconds; you’re going to be best served by using an OnUpdate function (where about half the function calls will do something useful and half will just decrement the timer).

(As a side note, accuracy of AnimationGroups is exactly the same as that of OnUpdate calls or C_Timer calls. They are all checked once per-frame.)
Rygarius/Others: Worth noting that LOOT_OPENED seems to be defunct now as an event. It fires -after- LOOT_CLOSED when you're autolooting, making it literally useless for that. A new event called "LOOT_READY" appears to fire when loot data has been available to the UI/Addons.
could someone fix this by any chance or is it not possible to macro this. /castsequence reset=2 Deep Freeze, Presence of Mind, Alter Time, Arcane Barrage, Arcane Blast, Alter Time, Arcane Barrage, Arcane Blast.
08/15/2014 03:49 PMPosted by Loukii
could someone fix this by any chance or is it not possible to macro this. /castsequence reset=2 Deep Freeze, Presence of Mind, Alter Time, Arcane Barrage, Arcane Blast, Alter Time, Arcane Barrage, Arcane Blast.

/castsequence will not skip abilities on cooldown. Macros like this have to be able to trigger everything, otherwise it will not finish the rest of the sequence when it reaches something on cooldown or unusable. This was a change some number of years ago to prevent one-button rotation macros.
PlaySoundFile() will not play custom ogg files. I tested this on the latest beta. One easy test anyone can do is use bugsack and set it fatality. It will not play. I also tested this with my own addon, and any sound that's not built in won't play.
08/22/2014 11:01 AMPosted by Galvin
PlaySoundFile() will not play custom ogg files. I tested this on the latest beta. One easy test anyone can do is use bugsack and set it fatality. It will not play. I also tested this with my own addon, and any sound that's not built in won't play.


Is this an intentional change or oversight? I would really like to see custom sound files back in the game.
I was just over here to see about PlaySoundFile myself. .ogg & .wav do not appear to be playing (which makes my ChatWatch add-on useless) I was wondering if it was a directory issue, or the call itself.

Yaara
..And I'm wondering when the chat logs are coming back. Every expansion it's the same thing, the chat.log is not generated, usually until 2 or 3 major patches in.... after i complain a few times. Can we get that fixed before the expansion comes out this time?

Yaara (Rhianidd's add-ons)
Latest build of beta still has custom sounds disabled. This goes live, raiding will be much harder with fewer sound choices.
Can we get a blue response regarding PlaySoundFile() in 6.0, please?
08/22/2014 11:01 AMPosted by Galvin
PlaySoundFile() will not play custom ogg files. I tested this on the latest beta. One easy test anyone can do is use bugsack and set it fatality. It will not play. I also tested this with my own addon, and any sound that's not built in won't play.

PlaySoundFIle() not working is a bug and should be fixed in a future Beta build.

In addition, functions that involve add-ons (GetAddonInfo, GetAddonDependances, etc.) should take the name or index.
Good to know.

Hopefully we can replace sounds too. On live we can use an .ogg in an appropriate Data/Sounds folder to mute or replace game sounds. On the beta, these files appear to have no effect.
http://www.wowinterface.com/forums/showthread.php?p=296508#post296508


Any chance of getting the C_PetJournal functions updated to work more like the new C_MountJournal functions, in that you can iterate over all the mounts without having to clear and restore all the filters? It's currently very tedious to work with the pet API, to such an extent that there's a dedicated library that does nothing but maintain an internal list of all the pets and provide a bunch of API wrappers. This seems like a clear case of designing the API around the UI, but it would be very nice to have an API that was just usable as-is.
http://www.wowinterface.com/forums/showpost.php?p=296513&postcount=20


Slightly off-topic, but can you ask them if they can fix the item quality returns for GetInboxItem and GetSendMailItem? It always returns -1, even though the default UI is now meant to show item quality borders for mail items.
Could we also get back the cost and powerType returns for GetSpellInfo()? Either that, or a new standalone function that returns this information. Right now, addons have to resort to tooltip scanning in order to determine the cost of a spell, which is tedious and resource-intensive. Plus, tooltips don't always reflect changes in spell costs right away. For example, gaining Thrill of the Hunt causes the tooltip to update immediately, but casting Bestial Wrath doesn't update the tooltip for sometimes up to ~700ms later.

All things considered, it seems silly that functionality was removed - if it was done so addons can't get information about spell costs, then it was futile, and otherwise it just creates more work for authors. I wrote a 200-line library to wrap around tooltip scanning, but I'm guessing that adding back those return values in C would be a great deal simpler than that.

I realize that the Blizzard UI doesn't use those return values, but there is a whole lot of other API functions that this Blizzard UI doesn't use either that are only of interest to addons. I would be forever appreciative if we get those return values back! Thanks!
09/10/2014 04:16 PMPosted by Galvin
Any chance of getting the C_PetJournal functions updated to work more like the new C_MountJournal functions, in that you can iterate over all the mounts without having to clear and restore all the filters? It's currently very tedious to work with the pet API, to such an extent that there's a dedicated library that does nothing but maintain an internal list of all the pets and provide a bunch of API wrappers. This seems like a clear case of designing the API around the UI, but it would be very nice to have an API that was just usable as-is.

This a hundred times. I was so happy to see how indexes worked in C_MountJournal. It would be incredible if C_PetJournal indexes worked the same way, and C_ToyBox too.

At present, in order to get a list of pets the user owns, and still allow the user to use journal filters:

- on login you have to hook C_PetJournal.SetSearchFilter and C_PetJournal.ClearSearchFilter to note what the user changes the search filter to at all times (there is no C_PetJournal.GetSearchFilter)
- when you need to get a list of pets, you then:
- save the states of all C_PetJournal.IsFlagFiltered, C_PetJournal.IsPetSourceFiltered, C_PetJournal.IsPetTypeFiltered.
- clear all the filters: C_PetJournal.SetFlagFilter the individual flags, C_PetJournal.AddAllPetSourcesFilter, C_PetJournal.AddAllPetTypesFilter and C_PetJournal.ClearSearchFilter (without overwriting what the legitimate search filter was prior to this process)
- get the list of pets
- C_PetJournal.SetSearchFilter to its original state, individually set all the C_PetJournal.SetFlagFilter, C_PetJournal.SetPetSourceFilter and C_PetJournal.SetPetTypeFilter to the states you saved them.

This is a ton of work to get a list of pets. So addons typically register for PET_JOURNAL_LIST_UPDATE, watch for number of owned pets changing, and then do all of the above and cache all pets into a separate table, and then work off that cached table instead of dealing with the journal mess.

Join the Conversation

Return to Forum