i get the message “AskMrRobot has been blocked from an action only available to the Blizzard UI. You can disable this addon and reload the UI.” every time i swtich specs with the addon
I haven’t seen that error before… we added in the behavior that changes your talents to match your chosen setup, but the new Blizzard APIs for changing talents are really wonky. Could be something going on with that.
That said, I didn’t get this error in any of my testing… does it always happen, or are there particular circumstances that seem to cause it?
This has happened for me once, but I was doing a few things, so AMR might not have been the actual culprit. If it happens again I’ll post the bugstack.
Thanks – the talent swapping is really finicky now… but we wanted to add the functionality back in preparation for the talent optimization features we’re building.
You can disable the talent swapping feature in the AMR addon options tab if it causes too many issues, we’re keeping an eye on bug reports.
It works best if you stand still and don’t press anything for a second or two after activating an AMR setup – the talents have a cast time and a little bit of a delay before they kick in.
I tried integrating with the saved loadouts in the new in-game talent UI… but that didn’t work well at all. Those APIs aren’t designed well for addon authors to use right now unfortunately.
Just a heads up, many addons are having functionality issues suspected to be blizzard related. Apparently everytime you change specs, change zones, leave your dragon flying mount, etc the macros or databases cease functioning until you reload the game. It’s like they don’t even exist. Been dealing with this issue on several addons ive been commiting on and as far as I am aware its something blizzard related as you can turn off all addons and create a macro ingame and it will lose its functionality doing the above. the error is likely caused by the addons trying to read or reference something that isnt there due to whatever blizzards issue is. for now, i would just reload any time you change zones, dismount your dragonflying, or change specs. it also doesnt happen 100% of the time and seems completely random 
That’s good to know, thanks for posting. I was unable to reproduce these errors so it’s good to know that I’m not crazy!
I’m hoping that they revisit some of the talent UI soon… not sure why Blizzard has such a hard time with the talent loadout features.
are you using the C_ClassTalents.ImportLoadout function and then using the C_ClassTalents.LoadConfig. I have an addon i’ve been working on to make sharing and importing between addon users using a drop down menu to send it without having to do the whole copy and paste crap(since you still can’t copy and paste out of chat without a fps loss chat addon lol) but it’s my first time working on using a back channel communication function so it’s not anywhere near ready.
But yeah since you are pulling from the website it might even be easier to show the import code and players manually import, then the addon could trigger the load config. And sorry i know this is off topic to the original post though.
Yeah I am able to use ImportLoadout – annoyingly it can only create a loadout, not update an existing one… but was able to work around that.
Calling LoadConfig is the problem… it sort of works… but most of the time the talent UI gets out of sync. If I have a loadout active called e.g. “test 1”, then I use ImportLoadout to create a config called “test 2”, then call LoadConfig to load “test 2”… it will actually change my talents to those in “test 2”, but the Blizzard talent UI will think that “test 1” is still active and get all wacky. Even if you reload your UI it is still confused.
There’s also some lag between creating a config, and that config being ready for use with LoadConfig.
I also tried using C_Trait to modify talents directly, but it lead to similarly unpredictable results. It also fails miserably unless the talent UI has been opened at least once before using most of the methods. I was able to hack around that by quickly opening/closing with ToggleTalentFrame… but put that approach on ice for the time being.
If you come up with any consistent way to use these APIs I’d love to hear it! In a couple weeks I’ll probably take another go at it and see if I can improve things a bit.
I’ll have time this weekend, but if im following what you are getting at, it seems there is a discrepancy between the import and call. are you saving the configid after the import then calling it?
as far as modifying directly using c trait, the only way I was able to get that to work was requesting a new config and then modifying, then saving. I havent tried using the loadconfig with that. I’ll play around this weekend. my addon only imports and saves it, so I havent tried messing with the load config too much.
Mhmm… yeah also this
there’s a functional divide between loadout configs, and the “active config”. Each spec has an “active config”, which contains all your active talents, regardless of what loadout you might have selected.
Whenever you activate a talent loadout by calling C_ClassTalents.LoadConfig, it will apply any required changes to your active config, which is why the TRAIT_CONFIG_UPDATED event payload holds the “active config” ID, rather than the loadout configID.
So for the time being until we find another work around, you’d probably have to import loadout, load config, then use C_ClassTalents.CommitConfig to lock it in. though you may end up having to delete excess profiles for it to work properly. Im not sure on that. Again i’ll try that out this weekend and see if it works properly.
Awesome, let me know what you find!
Yeah I figured out the whole “active config” vs. “saved config” thing early on – your saved loadouts never really become “active”, as your quote said, there is a single config for each spec I believe that just gets modified and is always “active”. Thus C_ClassTalents.GetActiveConfigID() always returns the same value.
ImportLoadout requires providing a config ID… for now I was using this “active” config ID. I’m not sure why it needs that… since it makes a new config… maybe it needs that to “base” it on that config? ImportLoadout does not return the ID of the new config that it creates – the only way I could figure out to find it after creation is to loop through the saved configs for the current spec and look for it by name.
I don’t know if I tried CommitConfig… maybe I can give that a shot.
If you look in the code for Blizzard’s talent tab, you can see it changing the selected saved config, and setting the state of the dropdown… but I couldn’t figure out how to access that to force the UI into the proper state, or any combination of API calls to make it update that state. It’s sort of a theme with Blizzard APIs though… they are deeply entwined with UI behavior when they really shouldn’t be.
I think i figured it out. Don’t have time to write it fully up, but if you get to it before i do,
(to import and swap based on known configids to avoid the issue with updating active spec instead of “swapping”)
C_ClassTalents.ImportLoadout(configID, entries, name)
then
C_ClassTalents.LoadConfig(configID, autoApply)
then
C_ClassTalents.UpdateLastSelectedSavedConfigID(specID [, configID]) *****pretty sure this is the handle for the dropdown menu and letting us know you swapped to a different spec option and should fix the ui error you mentioned.
(to create a new config using the ctraits)
C_ClassTalents.RequestNewConfig(name)
then
C_Traits.PurchaseRank(configID, nodeID) ****** Manually purchase all the ranks
or/then
C_Traits.CommitConfig(configID) ****** not sure if this will populate the tree with the configid you use. if not you might need to purchase ranks then pull the configid with C_Traits.GetConfigIDByTreeID(treeID) first and then use that for the commit.
then
C_ClassTalents.UpdateLastSelectedSavedConfigID(specID [, configID])
Also if you manually edit the tree using the ctraits you can use
C_ClassTalents.GetLastSelectedSavedConfigID(specID) after you save it to return that specific configid and then use it in the C_ClassTalents.LoadConfig(configID, autoApply)
Hey… so um… just found out they added this in game.
Loads loadout for the current specialization by name. This command will load the first one found in the case of duplicate names.
- /run ClassTalentHelper.SwitchToLoadoutByName(loadoutName)
- /loadoutname loadoutname
- /lon loadoutname
Loads loadout for the current specialization by dropdown index. Indices start at 1.
- /run ClassTalentHelper.SwitchToLoadoutByIndex(1)
- /loadoutindex 2
- /loi 3
Activates specialization for the current class by spec name.
- /run ClassTalentHelper.SwitchToSpecializationByName(specName)
- /specname specname
- /spn specname
Activates specialization for the current class by index in the order within the Specializations tab. Indices start at 1.
- /run ClassTalentHelper.SwitchToSpecializationByIndex(1)
- /specindex 2
- /spi 3
Interesting, i’ll play around with those macros a bit.
I tried the approach in your previous post, but the calls to UpdateLastSelectedSavedConfigID seemed to not do anything… whether I had the talent UI open or not (to rule out any issues with the frames not being initialized).
I also had to introduce delays between those commands sometimes… which made it pretty fragile for the end user…
I was moving over the last 2 days, finally got my internet service restored, so hopefully I can get back to this shortly.
So i’ve been up all night, and best i can figure is something is going wrong with the import function.
I’m able to create a button that allows you to click and change specs with no error using ClassTalentHelper.SwitchToLoadoutByName(); and the C_ClassTalents.LoadConfig(LoadoutId, true).
Also note, using both the functions didn’t require any ToggleTalentFrame() on my button
But so I messed with the amr gear.lua where it seems you’ve been placing these functions and I noticed this.
– actually loading/activating the loadout does not consistently work… revisit when Blizz gets the API working better
–[[
Amr.Wait(1, function()
– activate the new loadout
local newLoadoutId = nil
for i, c in ipairs(C_ClassTalents.GetConfigIDsBySpecID(specId)) do
local config = C_Traits.GetConfigInfo(c)
if config.name == “questing” then
newLoadoutId = c
no matter what I change the =“loadout name” to it only trys to switch to “Amr Latest Setup” which makes me think the “import” function itself is supposed to swap to the talents automatically when you import. so that could be causing the errors here. So either import or load, but not both. I know if you import in game it automatically switches to the imported loadout. So perhaps the function does the same.
So I see two options to remedy.
Either a. delete and import everytime we press the button(which would mean you would need to keep that import info persistent for every time they press the button)
or b. match the loadout ids/names with the exported data on website and just load using the name or id and people will have to manually alter their talent loadouts.
Yeah I guess the import function is trying to do something now that I try it some more… really messes up the talent UI. Sometimes it blanks all the talents, sometimes it makes the “apply changes” button flash but isn’t showing the correct talents…
If I could consistently figure out how to get the talent UI to activate a config that I create… I could probably just use C_Traits to then modify that config… might work better than trying to mess with the import function?
I am able to get it to switch consistently, but the talent frame drop down doesnt seem to update even though spec and everything works properly.
this is working for me. I just havent found a good way to make the loadout name a variable based on the loadout options my character has.
local a=C_ClassTalents
for i,id in ipairs(a.GetConfigIDsBySpecID())do
local c=C_Traits.GetConfigInfo(id)if c and c.name=="questing"then a.LoadConfig(id,true)
This works as intended except the talent frame doesnt update. After some testing it seems that the C_ClassTalents.UpdateLastSelectedSavedConfigID
is completely ignoring all other operations and executing as soon i load in regardless of the fact that it’s listed as part of a function onmouseclick. Trying to figure out why. i’ve tried putting a wait in there. I’ve tried running it as a separate function.
My head is hurting lol.
Other option to explore. Maybe when loadconfig executes the frame isn’t listening for the talents updated event? Perhaps if we registered it to, then maybe it would update. I don’t know much about registering events though, still pretty new to wow programming in general
I figured it out!
local a=C_ClassTalents
for i,id in ipairs(a.GetConfigIDsBySpecID())do
local c=C_Traits.GetConfigInfo(id)if c and c.name=="questing"then ClassTalentHelper.SwitchToLoadoutByName(c.name)
This updates both the talent frame and the dropdown menu automatically without having to open the window at all.
now all we have to do is replace “questing” with a variable or table to correlate with the selected amr profile
Plugged it into your load config section in gear.lua but the import function is causing an issue.
- imported profile with different spec then active
- pressed activate spec
- import function doesnt delete old amr latest setup
So removed the import loadout function for now. Maybe we could do the import talents as a separate option somewhere else maybe a new button separate from trying to swap loadouts.
so now we need to get the AMR=talent name for each loadout we create and import. not sure if it’s better to import that info from the website, or get it like we do in the export function. But anywho, I hope this helps some and maybe next update we can actually have loadouts change our specs for that loadout too!
local a=C_ClassTalents
for i,id in ipairs(a.GetConfigIDsBySpecID())do
local c=C_Traits.GetConfigInfo(id)if c and c.name==AMR then ClassTalentHelper.SwitchToLoadoutByName(c.name)
Awesome I’ll give it a try!
For now I had the code creating a single loadout that keeps getting updated each time you change your active setup. The reason is that Blizzard put a really low limit on the number of talent loadouts you can create… so if we were to make one for each of your Best in Bags setups, I think we would run out of loadouts for a lot of users.
I’ll see if I can keep that approach working, or if it will end up being better to create a loadout that matches each of your Best in Bags setups, and throw up some kind of error message if there aren’t enough available to create them all.
oh sorry i guess my suggestion was a little confusing the way i worded it.
I meant you could populate the ==AMR with the talent spec they chose when picking talents on the website and tying it specifically to each option in the addon dropdown menu “activate spec and gear”. You are already populating the website with the specinfo name when you hit edit talents you can see their created talent sets for the spec they chose. you would just need to feed the name of the chosen set.
The import loadout function would have to be entirely separate from this or removed all together.