Thank you so much for your reply, Master Iriel.

When you are mounted on a vehicle, the function UnitDetailedThreatSituation() always returns nil, so no threat data can be obtained. Likewise, UnitThreatSituation() always returns 0.

Also, the events UNIT_THREAT_LIST_UPDATE and UNIT_THREAT_SITUATION_UPDATE do not fire at all while mounted, until a mob dies, in which about 6 events fire at the same time at the death of the mob, with the listed arg1 after the event name.

UNIT_THREAT_LIST_UPDATE target
UNIT_THREAT_SITUATION_UPDATE vehicle
UNIT_THREAT_SITUATION_UPDATE pet
UNIT_THREAT_SITUATION_UPDATE raidpet2
UNIT_THREAT_SITUATION_UPDATE player
UNIT_THREAT_SITUATION_UPDATE raid2

So requests:
1. Make the threat functions and events work while mounted on a vehicle.
2. Make threat data available when my pet (or a party member) goes into combat with a mob, right now, I need to manually get on a mob's threat list before it starts returning threat data.

Please Slouken? :)

Not seeing threat data for Occulus or Malygos is a bit disturbing. (Not that they aren't killable.)

---

Q u o t e:


Thank you SO MUCH for adding this. I've been asking for it since I started work on my addon, FlightHUD:

http://wow.curse.com/downloads/wow-addons/details/flight-hud.aspx

I'd like to continue adding features to my addon, but to do so would require another addition to the API: The ability to obtain a players Z axis. I understand that this could be inconsistent across zones, but that shouldn't matter. Having _any_ sort of Z axis information would allow me to implement altitude, the height of a player relative to some sort of "sea level", which I would compute for each zone, and elevation, the height of a player relative to the ground. I would derive this by creating a table of ground elevation for every flyable (and perhaps even non-flyable) zone. The only thing I need from the API is a consistent Z axis value, and by consistent, I mean, it doesn't change across patches. I foresee this as being entirely doable on the client, so no server side code would be required. The API call should be a simple matter of returning the 3D engine's Z axis value.

Thanks,

Barf

---

Yes please! If nothing else, feet (/yards/units-of-measurement) above sea level (or absolute 0) would probably be much easier than feet above (impact) and would still be pretty fun.

Blizzard: If you're worried about exploits of some kind (not sure how or what) feel free to only enable this API when on flying mounts, and not in BGs or other vehicles, if you must. Anything is better than nothing here. FlightHUD makes flying so much more fun. If only our flight had "roll" too.

I'm posting this here rather than the Actual 3.0.2 changes thread as there was a request by ZootFizzle to keep that thread "as clean as possible" and to post here instead.

At post 26 Iriel said:

---

Q u o t e:
That behavior wouldn't be entirely inconsistent with other bits of the API.. I suspect you either need to make do with the summary level functions, or re-write your scanner to be event based.

(i.e. it's not a bug, and likely can't be changed)

---

Is this in reference to the immediately preceeding post about looping through Calendar events for that day? I can't understand the reference to "wouldn't be entirely inconsistent with other bits of the API" surely there are plenty parts of the API where you can loop round a list and call a function? eg: get names of players in a raid?

I'd like to be able to populate a simple UIDropDown with the names of the raids today. ie: something like :

numevents = CalendarGetNumDayEvents( 0, 0);
if ( numevents > 0 ) then
for i = 1, numevents do
CalendarOpenEvent( 0, 0, i );
title = CalendarGetEventInfo();
-- add title to drop down for selection
end
end

Are you saying this is not possible and is never going to be possible? If so could you suggest how I might get the titles of todays events?

Has the SecureHandlerShowHideTemplate been removed in 3.0.8?
A mod (Macaroon) that creates a frame inheriting this template now gives an error saying something like there's no such node. (Removing the reference to the template removes the error).

Many thanks. I'm still not 100% sure what event I should be using though. If I understand you correctly I can make a call to CalendarOpenEvent( 0, 0, i ) and that then queries the server for that event data. Once the server has populated the data it can then be queried by CalendarGetEventInfo()

From that I assume that the call to CalendarOpenEvent fires some event when it completes and CalendarGetEventInfo() is safe to be called? If so what is the event called please?

In SecureHandler.lua on PTR the following change was made:

--OnShow = Wrapped_ShowHide;
--OnHide = Wrapped_ShowHide;

Any particular reason? I relied on those to fix the long standing bug in the blizzard popup code where popups refuse to stop popping up once the mouse leaves, exits the window, the sky is blue, or whatever.

Does anyone have reliable code for popups that will absolutely 100% of the time close once the mouse leaves? I am really tired of having to come up with new fixes for such basic fundamental UI behavior. It is ridiculous for a popup to sometimes stay open once the mouse leaves. Please just finally fix the c code for this.

Or maybe add support for the following 2 things required for correct popup handling:

A global variable and api for THE ONE AND ONLY current popup frame. If you popup then the old one gets a close message or automatically hidden or whatever. You now become the open popup and the same courtesy is extended to you when a new popup is opened. Something like SetOpenPopupFrame(frame).

An actual working mechanism for delayed closing of a popup so you can can accidentally twitch your mouse out of the frame but get it back inside before the popup closes. This would be similar to previous things like the hover delay, except that it would actually always work, and not just sometimes work. This would require a timer, the expiry of the timer, and then actually closing the frame on expiry.

Is GetInstanceDifficulty() getting fixed, to properly return the difficulty of an instance? At the moment (both on the 3.0.3 live servers and 3.0.8 PTR) it gets "stuck" and will not properly return the difficulty of an instance. It appears this was likely broken in 3.0. This is easily replicated (thanks to Irvy for this test info):

* Check that dungeon difficulty is set to Normal.
* Enter Naxx
* /script print(GetInstanceDifficulty()) displays 1
* Leave Naxx
* Change dungeon difficulty to Heroic.
* Enter Naxx (hear entrance music that only plays on heroic mode)
* /script print(GetInstanceDifficulty()) displays 2

So far so good!

* Leave Naxx
* Change dungeon difficulty to Normal.
* Enter Naxx
* /script print(GetInstanceDifficulty()) displays 2
* Leave Naxx
* /script print(GetInstanceDifficulty()) displays 2

It is now stuck on 2. The 2 survives a reloadui.


At this point in time, it is a crapshoot whether the function will return the proper value or not, making it impossible to reliably tell what difficulty dungeon a character is in.

Wow, all the timer and onupdate code was removed as well. I see no mechanism replacing it. How would one for example close a popup after a 1 second delay?

---

Q u o t e:
I believe the details are in RestricedExecution.lua.

---

I checked the file, and if I understand how the code works, I believe it is bugged and does not function as indicated.

local LOCAL_Animation_Methods = {

    Show = true;

    Hide = true;

    SetPoint = true;

    SetScale = true;

    SetHeight = true;

    SetWidth = true;

    SetAlpha = true;

};



function LOCAL_Animation_Namespace.SetUpAnimation(frame, updateFunc, posBody, totalTime, postFunc, reverse)

    if ((updateFunc ~= nil) and not LOCAL_Animation_Methods[updateFunc]) then

        error("Unsupported secure animation function '" .. updateFunc .. "'");

        return;

    end

    if ((postFunc ~= nil) and not LOCAL_Animation_Methods[postFunc]) then

        error("Unsupported secure animation function '" .. postFunc .. "'");

        return;

    end

    SetUpAnimation(GetFrameHandleFrame(frame),

                   {

                       updateFunc = updateFunc;

                       getPosFunc = LOCAL_Animation_Closures[posBody];

                       totalTime = tonumber(totalTime) or 0;

                   },

                   postFunc,

                   (reverse or nil) and true);

end

The LOCAL_Animation_Namespace.SetUpAnimation function implies that the postFunc needs to be a string, since it is checking the name in the table. Then, after the check passes, the postFunc is passed to the official SetUpAnimation function and is assigned to the variable animPostFunc. This is problematic because the function is just a string, not a function. So, when the animation code is actually processed from the AnimationSystem.lua file:

local function Animation_UpdateFrame(self, animElapsed, animTable)

    local totalTime = animTable.totalTime

    if ( animElapsed and (animElapsed < totalTime)) then	--Should be animating

        local elapsedFraction = self.animReverse and (1-animElapsed/totalTime) or (animElapsed/totalTime);

        animTable.updateFunc(self, animTable.getPosFunc(self, elapsedFraction));

    else	--Just finished animating

        animTable.updateFunc(self, animTable.getPosFunc(self, self.animReverse and 0 or 1));

        self.animating = false;



        AnimatingFrames[self][animTable.updateFunc] = 0;	--We use 0 instead of nil'ing out because we don't want to mess with 'next' (used in pairs)

		

        if ( self.animPostFunc ) then

            self.animPostFunc(self);

        end

    end

end

The aninPostFunc which was assigned a string value will cause an error.

Maybe I'm misunderstanding something, but with the code as it is now, there is no way for us to add a timed animation that simply hides a frame after x seconds. If we want an actionbar menu to appear when we mouse over a section of the screen and then disappear 3 seconds after we moused away from the frame, the code will not work. I guess I can use the position function and make sure the position is always the same during the time the timer is running, and then set the position to be some crazy (-1000, -1000) or something so it appears off the screen, but that's a little silly. Do we really have to resort to that to get auto-hide and auto-show stuff to work again?

---

Q u o t e:

I checked the file, and if I understand how the code works, I believe it is bugged and does not function as indicated...

---

Thank you for saving me a lot of typing. I do not just believe, I know it is not functioning as intended, unless you are able to call it via the internal API that only Blizzard code can do.