Is GetTexture() bugged? I've been struggling for ages with a buff reminder script which works on live but doesn't on beta. It behaves extremely strangely: GetTexture() (in this case at least) returns nil, while a valid texture is set. This code, for instance:

Does anyone know of an easy way to determine the player's active specialization? I've been digging through the interface code and I haven't found anything beyond maybe trying to manually set the talent frame to the active spec and checking PlayerTalentFrameSpecializationSpecButton(1-3).selected

(which is true if it is, the only problem being that it's only for the tab that's currently selected on the talent screen)

Does anyone know of an easy way to determine the player's active specialization? I've been digging through the interface code and I haven't found anything beyond maybe trying to manually set the talent frame to the active spec and checking PlayerTalentFrameSpecializationSpecButton(1-3).selected

(which is true if it is, the only problem being that it's only for the tab that's currently selected on the talent screen)

I must be missing something >.>

GetSpecializationInfo(GetSpecialization())

--------
It seems like the world's map size has become very inconsistent. Depending on where I measure it from, it gives me different results.

World's width and height in yards as measured from
Kalimdor: 59547.144977691 39698.085269174
Eastern: 59325.077732756 39550.030762135
Northrend: 56143.874550054 37429.26435188
Pandaria: 51274.202252344 34182.772393128
Maelstrom: ? ? (doesn't seem to be part of the world at all, like Outland)

Coordinates are completely broken in Dalaran, no player arrow appears on its map.

On live servers I always get around 47714 and 31809, regardless of which continent I derive it from.

I don't know the answer to that specifically, but there is definitely some kind of issue going on with textures. In Grid, the NormalTexture on each unit button is hidden by setting its opacity to 0 with button:SetNormalTexture(1, 1, 1, 0). As far as I know, this is Pastamancer's original code that's been there since 2006. On the MoP beta servers, however, every frame's NormalTexture was set to a hideous neon green color, and button:GetNormalTexture():GetTexture() returned the number 0 instead of a string. The only way I could get rid of the awful green was to do button:SetNormalTexture("") to remove the texture entirely. Between there being no code in Grid or anywhere else that I could find that should be applying a neon green color to the NormalTexture of anything, and :GetTexture() returning a 0, I'd say there's definitely at least one bug they're (hopefully) working out.

Only change I've noticed with textures is I get green squares if the texture path is invalid, can't remember if that's also present on live though. Not having any other issues thus far, but I'm not creating any frames/textures until after ADDON_LOADED has fired at the very earliest.

Animations are still very jumpy though if you combine them, for instance a Scale and Rotation animation both playing at the same time on a single frame will often make it vanish or jump in size for a frame or two pretty frequently.

That neon green texture error was in Cataclysm beta aswell. It had sth to do with texture loading and addon folders. (Sth like that...)
By the time the texture was set it was unknown to the system and resulted in a bright green texture instead.

Like p3lim wrote. If the texture is unknown to the client for whatever reason you get a bright green texture.

I'm currently having no texture errors but I'm still at the beginning.

@Haleth

What happens if you do this:

Lua Code:

frame:SetTexture("Interface\\Icons\\Spell_Holy_InnerFire")

or

Lua Code:

frame:SetTexture([[Interface\Icons\Spell_Holy_InnerFire]])

Afaik double backslashes are needed if the texture name is used directly. There is an alternative way to write it without the leading backslash. Phanx or p3lim should know it. Sth like [[TEXTUREPATH]] or [=[TEXTUREPATH]=]https://github.com/haste/oUF/blob/4f...ction.lua#L116

Afaik double backslashes are needed if the texture name is used directly. There is an alternative way to write it without the leading backslash. Phanx or p3lim should know it. Sth like [[TEXTUREPATH]] or [=[TEXTUREPATH]=]

Code:

"All \"special\" characters like \\ must be escaped."

Code:

[[All "special" characters like \ are fine as-is.
Also, line breaks work.
Even double line breaks!]]

Code:

[=[For when you want literal [[double brackets]] in your
"double bracketed string" with \backslashes and line breaks.]=]

Code:

[=======[For when you really like lots of equals signs,
or for some reason want a literal [=[ or [====[ in your string.
As long as there are the same number on both sides,
it doesn't matter how many there are.]=======]

nUI's button bag icons have that problem as well. Will have to investigate how their images are being set if it looks like there is some sort of validation that has been enforced this time.

Also, while I am typing this, can anyone recall whether it was getglobal being phased out to _G or the other way round. I'm sure the _G were being forced to getglobal at some point but for the life of me I can't remember 100%.

Also, while I am typing this, can anyone recall whether it was getglobal being phased out to _G or the other way round. I'm sure the _G were being forced to getglobal at some point but for the life of me I can't remember 100%.

getglobal is deprecated in favour of _G, however the function still exists.