WoWInterface

WoWInterface (https://www.wowinterface.com/forums/index.php)
-   MoP Beta archived threads (https://www.wowinterface.com/forums/forumdisplay.php?f=162)
-   -   Beta API discussion (https://www.wowinterface.com/forums/showthread.php?t=43091)

Shadowed 08-24-12 04:24 PM

Quote:

Originally Posted by Meorawr (Post 260192)
To extend on Miiru's post, player models for units under DX9 and OpenGL (on Windows) are very broken.

Under DX9, the models aren't being constrained to the bounds of the model frame. Rather than being clipped by the edges of the frame (which gives that floating 3D head), the models aren't clipped and you get the entire unit in the display. Due to the in-built camera positioning the models appear slightly distorted as a result, but that's not really a problem (the "head" portion will appear perfectly fine).

Under OpenGL, and this was only tested on Windows, the 3D models simply aren't being rendered at all. This might have been a config issue (I just force set gxAPI to "OpenGL").

Edit: Not sure if this is the case on live, but I just noticed that the GetNumber (and possibly SetNumber) methods available to editboxes use floats internally which causes some unfortunate wrapping behaviour (values from 0-16777215 are fine, 16777216+ will be flattened to the nearest 2). Anyone mind checking if this is a difference from live?

Does the model issue happen on the character create screen too, or is it just in-game on portraits? Might be an issue with only addons.

Meorawr 08-24-12 05:30 PM

It's only with the 'face-cam' style portraits, Miiru might have more information (I was just expanding upon what I noticed when I took a look, purely out of interest).

Tested with Simple3DPortraits.

Screenshots of the differences: DX11/DX9/OpenGL

Also, while taking those screenshots I checked out the character creation screen and got these results: DX11/DX9/OpenGL

Basically, OpenGL in the character creation screen behaved similarly to the DX9 results from ingame. DX9 was broken ingame, but fine on the creation screen. DX11 was fine on both.

Cybeloras 08-29-12 11:12 PM

Quote:

Originally Posted by Meorawr (Post 259496)
UnitAura seems to have changed but I couldn't find this mentioned anywhere. More importantly it's behaving in a really horrible way.

On live there's 13 return values (name through to isBossDebuff) plus an additional 3 return values for tooltip information.

In the latest build there's a minimum of 14 return values, the last one being a boolean. You'd expect the 3 tooltip values to then be values 15-17, however here's how it works for the following two buffs:

Legacy of the White Tiger:

14 return values, last one is a boolean. Values 15-17 aren't returned (so they're nil, effectively).

Life Cocoon:

17 return values, however 14-16 are the tooltip values, whereas this mystery boolean is #17.

Basically it's a major pain now because whereas we could (hopefully) have assumed #14-16 to be nil/number values, we now have to check if #17 is not nil in order to determine whether or not tooltip values exist.

Of course I could be completely missing something here so do correct me if I'm wrong :)

/dump's of the returns:

<snip>

In short the stack needs 0's or nil's at 14-16 for the first case :)

I just noticed this too while updating TellMeWhen. I wrote a quick script to pull buff and debuff information from anyone I targeted, went to the training dummies in Org, and went crazy targeting everyone I could find.

Here is a CSV of the results: http://pastebin.com/pBczmavs (Save it with a .csv extension and open it with Excel/OO Calc/etc.)

The point was basically to see if there was any pattern to what that last boolean is, but I couldn't figure it out. Perhaps with a bigger sample set we could notice something.

Meorawr 08-30-12 05:22 AM

I spoke to one of the UI devs about it actually (forgot to follow up on it). It's a known issue, but they weren't able to fix it before the release. It's intended to be at return index #14, and the boolean is (iirc) castByPlayerCharacter.

Should be fixed in a future patch, but until then it's being pushed onto the end of the stack. Just wrap returns #14-17 in a "tonumber(<var>) or 0" until then.

Meorawr 08-31-12 02:18 PM

Latest beta build no longer crashes the client when using fontstrings with just the MONOCHROME style set. That's the good news.

The bad news is the text isn't rendered.

zork 09-01-12 06:27 AM

So their fix was to disable it completly? Nicely done.

p3lim 09-01-12 07:36 AM

Monochrome still works for me, both on live and beta :s

Meorawr 09-01-12 08:55 AM

If you're combining it with an outline style, it works perfectly fine.

Oh and I take back what I said about it not crashing. I think my quick test on it yesterday did something odd - either that or the bug doesn't always result in a client crash.

Test #1: Works, creates the fontstring and displays "BANANAS!" at size 32 with an outline.
Lua Code:
  1. local __T = UIParent:CreateFontString();
  2. __T:SetFont([[Fonts\FRIZQT__.ttf]], 32, "OUTLINE");
  3. __T:SetText("BANANAS!");
  4. __T:SetPoint("CENTER");

Test #2: Works, same as above but with the MONOCHROME style added.
Lua Code:
  1. local __T = UIParent:CreateFontString();
  2. __T:SetFont([[Fonts\FRIZQT__.ttf]], 32, "MONOCHROME, OUTLINE");
  3. __T:SetText("BANANAS!");
  4. __T:SetPoint("CENTER");

Test #3: Crashes, no outline style specified.
Lua Code:
  1. local __T = UIParent:CreateFontString();
  2. __T:SetFont([[Fonts\FRIZQT__.ttf]], 32, "MONOCHROME");
  3. __T:SetText("BANANAS!");
  4. __T:SetPoint("CENTER");

p3lim 09-01-12 09:08 AM

Afaik it's :SetFont(font, size, 'OUTLINEMONOCHROME')

Meorawr 09-01-12 09:09 AM

It's very free-form for that particular argument - I think separating it by pipes also works. Either way, MONOCHROME all by its lonesome causes crashes.

The comma delimiter works perfectly fine, since I was just copy/pasting that test from what I did in-game :)

What's more interesting about the bug is it outright crashes the client and doesn't give the standard error dialog for reporting it.

Phanx 09-01-12 07:45 PM

Quote:

Originally Posted by p3lim (Post 261728)
Afaik it's :SetFont(font, size, 'OUTLINEMONOCHROME')

The correct usage is to separate the flags by a comma or pipe character. See also:
http://www.wowpedia.org/API_FontString_SetFont

myrroddin 09-02-12 06:51 AM

Hmm, I just tested outline and monochrome in SmartRes2. Outline works, of course, but monochrome does not throw errors and crash the game. Instead, it blocked out the text on the resurrection bars so you could not read the caster, target, or cast time.

Tuller 09-04-12 11:51 AM

I made a request for a few more presents for Blizzard with respect to the various special action bars:
http://us.battle.net/wow/en/forum/topic/6490559996#1

I still need to run through the The Prophet Tharon'ja encounter in Drak'Tharon Keep. I believe it uses the temp shapeshft action bar, and not [overridebar] or [possessbar]

p3lim 09-04-12 01:22 PM

Quote:

Originally Posted by Tuller (Post 262331)
I still need to run through the The Prophet Tharon'ja encounter in Drak'Tharon Keep. I believe it uses the temp shapeshft action bar, and not [overridebar] or [possessbar]

Just tested it, you're correct.

p3lim 09-04-12 01:43 PM

Quote:

Originally Posted by Tuller (Post 262331)
I made a request for a few more presents for Blizzard with respect to the various special action bars:
http://us.battle.net/wow/en/forum/topic/6490559996#1

Code:

local frame = CreateFrame('Frame', nil, UIParent, 'SecureHandlerStateTemplate')
frame:SetAttribute('_onstate-page', [[
    print(newstate)
]])

RegisterStateDriver(frame, 'page', '[overridebar] override; [petbattle] petbattle; [form:3] cat; none')

It will print "override" equal to HasOverrideActionBar()
It will print "petbattle" when doing a petbattle
It will print "cat" when in cat form (druid)
It will print "none" if none of the above

I would like to see [tempshapeshiftbar] or something along those lines though.

Edit:
Something like this would work
(keep in mind the indexes are not correct, I just used them randomly)
Code:

local states = ''

for state, index in pairs{
        ['[vehicleui]'] = 1,
        ['[possessbar]'] = 2,
        ['[overridebar]'] = 3,
--        ['[tempshapeshiftbar]'] = 4,
} do
        states = states .. state .. index .. ';'
end

local frame = CreateFrame('Frame', nil, UIParent, 'SecureHandlerStateTemplate')
frame:SetAttribute('_onstate-page', [[ print(newstate) ]])
RegisterStateDriver(frame, "page", states .. 'none')


p3lim 09-04-12 02:34 PM

Quote:

Originally Posted by Tuller
Finally, does the new [overridebar] macro condition cover the following two cases?

* When a user has special buttons for entering a vehicle, but no vehicle interface
* When a user has a temporary shape shift bar

1: No, that is covered by [possessbar] in most cases
2: Nothing covers that

Tuller 09-05-12 06:41 AM

That's basically what I expected to be the case. I don't like states we can't detect :P

jaliborc 09-05-12 11:36 AM

Quote:

Originally Posted by Tuller (Post 262449)
That's basically what I expected to be the case. I don't like states we can't detect :P

Yes, it's quite restrictive. Hope they implement your request.

Tuller 12-07-12 09:05 PM

Blizzard was sneaky, and I never noticed these additions to the restricted environment:
"HasVehicleActionBar",
"HasOverrideActionBar",
"HasTempShapeshiftActionBar",
"HasOverrideUI",
"GetVehicleBarIndex",
"GetOverrideBarIndex",
"HasExtraActionBar",
"GetTempShapeshiftBarIndex",
"CanExitVehicle"

Unfortunately, HasOverrideUI doesn't actually map to anything, though.


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

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