WoWInterface

WoWInterface (https://www.wowinterface.com/forums/index.php)
-   Legion Beta archived threads (https://www.wowinterface.com/forums/forumdisplay.php?f=177)
-   -   Default Actionbars and ActionButtons (https://www.wowinterface.com/forums/showthread.php?t=53487)

semlar 06-02-16 04:48 PM

You don't need the functions to return the correct value, you have newstate from the macro condition which means you know which page it should be set to.

zork 06-03-16 02:13 AM

My newstate returns strings. I do not work with preset actionpage numbers.

semlar 06-03-16 04:55 AM

Quote:

Originally Posted by zork (Post 315412)
My newstate returns strings. I do not work with preset actionpage numbers.

Each macro condition is associated with a specific bar. When your macro condition triggers a new state, it calls your attribute and tells it which bar is now active.

If you use a condition like [form:1] form1; [form:2] form2; [form:3] form3; [form:4] form4, you don't need the api function to check which form you're in because it's being passed via newstate to your attribute.

This is good, because GetShapeshiftForm() is generally wrong about what form you're shifting into when the condition fires and returns the form that you're shifting out of due to the order of events.

You can try it yourself by making a druid on the beta, I wouldn't be surprised if other conditions are also capable of firing before the api function returns valid data.

Lua Code:
  1. local driver = CreateFrame('Frame', nil, nil, 'SecureHandlerStateTemplate')
  2. RegisterStateDriver(driver, 'form', '[noform]0;[form:1]1;[form:2]2;[form:3]3;[form:4]4')
  3. driver:SetAttribute('_onstate-form', "print('_onstate-form:', newstate, 'GetShapeshiftForm:', GetShapeshiftForm())")

zork 06-03-16 06:59 AM

Thanks. I have no problems with form swaps though. Those are handled by the bonusbar condition just fine.

I had the problem once when going in a vehicle. Vehicle, Override, Possessbar and Tempshapeshift bar do not have individual action bar pages. For now I ingore that bug as an error that will happen in like 1/1000 or whatever. I cannot even reproduce it.

------------------------

Either way since you are posting on forms. I have a different request on that part.

I want to display the stancebar only if a player has GetNumShapeshiftForms() > 0. Sadly GetNumShapeshiftForms is not part of the restricted environment. Thus if I have this visibility condition on a stancebar: "[stance][form] show; hide" it will hide the stancebar when the user goes out of any stance. (Rogues, Druids)

Here is my idea. Can I get the value from GetNumShapeShiftForms() and save it on the bar and access that value in the restricted environment? Should be if I use Execute and set up a reference or am I mistaken?

semlar 06-03-16 07:23 AM

Quote:

Originally Posted by zork (Post 315416)
Here is my idea. Can I get the value from GetNumShapeShiftForms() and save it on the bar and access that value in the restricted environment? Should be if I use Execute and set up a reference or am I mistaken?

Yeah, you can just call something like frame:Execute('NumShapeshiftForms = ' .. GetNumShapeshiftForms()) on PLAYER_LOGIN or whenever you think it might change, as long as you're out of combat. You could even call it upon entering combat if you wanted to.

The value would probably only ever change for a leveling druid who just picked up a new form, or maybe switching specs, where you'd gain and lose moonkin form.

From what I can tell the stance bar only monitors the "UPDATE_SHAPESHIFT_COOLDOWN" event to handle hiding and showing the proper buttons, however UPDATE_SHAPESHIFT_FORMS might be a better event to watch.

Look, you can't have an action bar addon that works most of the time. It has to work all of the time, and if the api functions have the potential to ever return the incorrect values due to the order of events being undefined, you simply can't use them. You have to hardcode the bar offsets and pass them based on which macro condition fired.

zork 06-03-16 11:23 AM

semlar I am not even sure what may have caused it. Maybe I even had a bug in my code. It is working just fine atm.

Regarding the stancebar issue: I'm delaying stancebar creation until I can access the number of stance slots and only create the frame if the returned number is > 0.

semlar 06-03-16 01:01 PM

Quote:

Originally Posted by zork (Post 315428)
semlar I am not even sure what may have caused it. Maybe I even had a bug in my code. It is working just fine atm.

Could be, but what you were describing sounded like the same exact issue I ran into with GetShapeShiftForm not returning accurate information when the state driver was executed because the events weren't guaranteed to fire in a specific order.

I'm just wondering if there's any reason to not use static values for the bar offsets.

Bonus bars are 7-10, "possess bar" is 11, "vehicle bar" is 12, "temp shapeshift bar" is 13, "override bar" is 14.

Are these values even capable of changing? They're just mapping the buttons to action slots (index-1) * 12 + button number.

zork 06-03-16 01:18 PM

Your nagging made me go to a quest that I knew from Wrath that always made problems.
You are right. Exactly the case on that quest. >_>
Returns wrong bar index upon entering. At least I now have a testcase.
http://imgur.com/EQxZUEx
Of course the bar index is correct after reload or if I add a wierd condition like modifier and hit CTRL.

Changed it back to
Lua Code:
  1. for i, button in next, buttonList do
  2.     frame:SetFrameRef(cfg.buttonName..i, button)
  3.   end
  4.   frame:Execute(([[
  5.     buttons = table.new()
  6.     for i=1, %d do
  7.       table.insert(buttons, self:GetFrameRef("%s"..i))
  8.     end
  9.   ]]):format(cfg.numButtons, cfg.buttonName))
  10.   frame:SetAttribute("_onstate-page", [[
  11.     for i, button in next, buttons do
  12.       button:SetAttribute("actionpage", newstate)
  13.     end
  14.   ]])
  15.   RegisterStateDriver(frame, "page", "[overridebar]14;[shapeshift]13;[vehicleui]12;[possessbar]11;[bonusbar:4]10;[bonusbar:3]9;[bonusbar:2]8;[bonusbar:1]7;[bar:6]6;[bar:5]5;[bar:4]4;[bar:3]3;[bar:2]2;1")

Now what might happen is that the condition does not match the actual bar-id in some cases. Because I know of some quests that trigger for possessbar and show stuff in the vehiclebar under index 12 (if I'm not totally mistaken).

Will keep it at that for now until further issues occur. :)

Code:

/run local s=SecureCmdOptionParse print(s("[bonusbar]bb;no-bb"),s("[canexitvehicle]cev;no-cev"),s("[overridebar]ob;no-ob"),s("[possessbar]pb;no-pb"),s("[shapeshift]ss;no-ss"),s("[vehicleui]vui;no-vui"),s("[@vehicle,exists]ve;no-ve"))
/run print("vb"..GetVehicleBarIndex(), "ob"..GetOverrideBarIndex(), "tss"..GetTempShapeshiftBarIndex(), "bb"..GetBonusBarIndex(), "ab"..GetActionBarPage())
/run print(HasVehicleActionBar() or "nov-ab", HasOverrideActionBar() or "no-ob", HasTempShapeshiftActionBar() or "no-tss", HasBonusActionBar() or "no-bb")


zork 07-26-16 12:03 PM

Just to post it here. Razorgore fight is using the possessbar condition. But there are no buttons for action bar index 11 for that condition. Instead it is using the same action bar index as vehicleui which is 12.

http://imgur.com/a/w95MV
http://imgur.com/a/Xr5K8

I changed the state driver for bar1 to:
Lua Code:
  1. RegisterStateDriver(frame, "page", "[overridebar]14;[shapeshift]13;[vehicleui]12;[possessbar]12;[bonusbar:5]11;[bonusbar:4]10;[bonusbar:3]9;[bonusbar:2]8;[bonusbar:1]7;[bar:6]6;[bar:5]5;[bar:4]4;[bar:3]3;[bar:2]2;1")

Mind Control is using action bar index 12 aswell:
http://imgur.com/a/aNGiR


All times are GMT -6. The time now is 08:01 AM.

vBulletin © 2024, Jelsoft Enterprises Ltd
© 2004 - 2022 MMOUI