Thread Tools Display Modes
09-21-13, 10:28 PM   #1
fostic_popcorn
A Murloc Raider
 
fostic_popcorn's Avatar
AddOn Author - Click to view addons
Join Date: Oct 2008
Posts: 5
SetFont errors in 5.4

Hey all, I'm running into a really odd set of SetFont related errors in my text-based Unit frames. Specifically this:

Message: ...ddOns\UnderHood\libs\LibDogTag-3.0\LibDogTag-3.0.lua:312: Usage: <unnamed>:SetFont("font", fontHeight [, flags])
I have updated LibDogTag-3.0 to it's 5.4 updated version to no avail.

After doing some digging this issue appears to have struck multiple add-ons, including KuiNameplates, Shadowed Unit Frames, and Pitbull Unit Frames.

I'm not a real programmer, so I have no idea how to fix this. It appears to target addons that create buckets of fonts from users to choose from, and it appears to have something to do with when the fonts are loaded (at login?). Any advice you could give me would be much appreciated.
  Reply With Quote
09-21-13, 11:03 PM   #2
Dridzt
A Pyroguard Emberseer
 
Dridzt's Avatar
AddOn Author - Click to view addons
Join Date: Nov 2005
Posts: 1,359
This is an issue that stems from an assumption several addons make that the ADDON_LOADED event for the specific addon in question, generally fires before the PLAYER_LOGIN event.

This was indeed the case for all statically loaded addons (not load on demand) prior to 5.4.

The significance of those 2 events is that ADDON_LOADED with 'myaddon' as arg1 tells the author that saved variables are loaded and it's safe to do settings initialization, while PLAYER_LOGIN tells the author that they now have available most game systems (things like player talents, etc) so it's safe to query those.

This is mirrored in the Ace3 initialization scheme as well with :OnInitialize() corresponding to ADDON_LOADED for our addon, and :OnEnable() corresponding to PLAYER_LOGIN.

Many authors got into the habit of doing initialization on PLAYER_LOGIN since it was assumed (and for a very long period of time actually worked like that) that it always fires later than ADDON_LOADED.

This is no longer the case and PLAYER_LOGIN can fire earlier in the loading process than ADDON_LOADED for 'our addon' on some systems or for the same player from login to login.

So trying to reference for example fonts in PLAYER_LOGIN assuming the addon has already processed its saved variables in ADDON_LOADED and knows what font to apply won't always work.

The way to fix this is to put checks in place that ensure you do your initialization explicitly in the order you intended and not implicitly assuming a specific ADDON_LOADED -> PLAYER_LOGIN sequence.

Since you cannot get around the fact that your saved variables load at ADDON_LOADED my preferred method for ensuring I do initialization properly is something like this

Code:
events.ADDON_LOADED = function(addonName)
  if addonName == "myAddon" then
    -- InitSVStuff()
    if IsLoggedIn() then
      events.PLAYER_LOGIN()
    else
      events:RegisterEvent("PLAYER_LOGIN")
    end
  end
end
events.PLAYER_LOGIN = function()
  -- InitGameStuff()
end
This ensures that PLAYER_LOGIN and any extended initialization I need to do there always runs after ADDON_LOADED and any saved variables related setup I need to do first.

I put similar safeguards in AceAddon-3.0 based addons with the :OnInitialize() and :OnEnable() functions after 5.4.
  Reply With Quote
09-22-13, 02:52 PM   #3
tuff
A Defias Bandit
Join Date: Sep 2010
Posts: 2
Some of you may not be aware that there is a new Beta Battle Net Launcher available to WoW players.

The launcher allows us to sign in and use it to access our Blizzard games (ie WoW, Diablo, Starcraft, the new Hearthstone etc..). We enter our account and password (and authenticator if present) one time - bringing up a menu screen where we can choose to play a game, go to our account management, see any breaking news and see which Real ID friends are online and where they are in game.

Starting a game through this launcher completely bypasses the original login screen - taking you directly to the character selection screen, so it appears that the game(s) consider you already "logged in" at the time you enter your info into the launcher.

This could be why the Player Login events no longer function as they used to.
  Reply With Quote
09-22-13, 03:13 PM   #4
Dridzt
A Pyroguard Emberseer
 
Dridzt's Avatar
AddOn Author - Click to view addons
Join Date: Nov 2005
Posts: 1,359
Originally Posted by tuff View Post
Some of you may not be aware that there is a new Beta Battle Net Launcher available to WoW players.

The launcher allows us to sign in and use it to access our Blizzard games (ie WoW, Diablo, Starcraft, the new Hearthstone etc..). We enter our account and password (and authenticator if present) one time - bringing up a menu screen where we can choose to play a game, go to our account management, see any breaking news and see which Real ID friends are online and where they are in game.

Starting a game through this launcher completely bypasses the original login screen - taking you directly to the character selection screen, so it appears that the game(s) consider you already "logged in" at the time you enter your info into the launcher.

This could be why the Player Login events no longer function as they used to.
Thanks, that's interesting but the PLAYER_LOGIN event fires for the character logging into the game not the account
So it hasn't fired at the character selection screen regardless if you bypassed the account login.
  Reply With Quote
09-22-13, 03:13 PM   #5
Haleth
This Space For Rent
 
Haleth's Avatar
Featured
Join Date: Sep 2008
Posts: 1,173
Tuff: The PLAYER_LOGIN event has always been about the character logging in, not the authentication process that takes you to the character screen (where addons can't do anything).

Edit. Beaten to it
  Reply With Quote
09-22-13, 03:32 PM   #6
fostic_popcorn
A Murloc Raider
 
fostic_popcorn's Avatar
AddOn Author - Click to view addons
Join Date: Oct 2008
Posts: 5
Thanks for your response Dridtz. That helps me understand why it broke this patch at least.

Since this is a moduled UnitFrames that I'm using, I'm not sure where to put in these checks. Do I put it in the core/main.lua file of the add-on? Or in LibDogTags-3.0.lua? Or in the Texts module file?

Additionally, this addon uses Ace-3.0. So would it be easier to check for AddOn:IsEnabled() rather than PLAYER_LOGIN?

Sorry for the stupid questions, theoretically I think I understand the problem but practically I don't know where to fix it.
  Reply With Quote
09-22-13, 03:48 PM   #7
Dridzt
A Pyroguard Emberseer
 
Dridzt's Avatar
AddOn Author - Click to view addons
Join Date: Nov 2005
Posts: 1,359
Originally Posted by fostic_popcorn View Post
Thanks for your response Dridtz. That helps me understand why it broke this patch at least.

Since this is a moduled UnitFrames that I'm using, I'm not sure where to put in these checks. Do I put it in the core/main.lua file of the add-on? Or in LibDogTags-3.0.lua? Or in the Texts module file?

Additionally, this addon uses Ace-3.0. So would it be easier to check for AddOn:IsEnabled() rather than PLAYER_LOGIN?

Sorry for the stupid questions, theoretically I think I understand the problem but practically I don't know where to fix it.
They're not stupid questions at all, unfortunately I can't reply unless I know the addon in question to take a look at the code.
  Reply With Quote
09-22-13, 10:29 PM   #8
Mikord
A Theradrim Guardian
AddOn Author - Click to view addons
Join Date: Jul 2006
Posts: 61
There is another issue around SetFont that I haven't been able to figure out yet either. For example, with MSBT, I don't do anything in PLAYER_LOGIN at all. It's all done in ADDON_LOADED. There are no errors, but it just doesn't set the font to the saved value even though I've added prints and prove it is in fact calling SetFont with the appropriate data. This can be seen in the options too where you select a different font which updates a preview font string, but it doesn't change it every time. I have found that, unlike before, you have to change the text string to actually make it take effect, but that doesn't seem to totally fix it either. I'm not sure if it's related to strata or frame levels or what, but something clearly changed and wasn't documented.
  Reply With Quote
10-01-13, 01:29 PM   #9
Esamynn
Featured Artist
Premium Member
Featured
Join Date: Jan 2005
Posts: 395
I know I'm late to the party here, but I just can't leave this alone.

Originally Posted by Dridzt View Post
This is an issue that stems from an assumption several addons make that the ADDON_LOADED event for the specific addon in question, generally fires before the PLAYER_LOGIN event.

This was indeed the case for all statically loaded addons (not load on demand) prior to 5.4.

The significance of those 2 events is that ADDON_LOADED with 'myaddon' as arg1 tells the author that saved variables are loaded and it's safe to do settings initialization, while PLAYER_LOGIN tells the author that they now have available most game systems (things like player talents, etc) so it's safe to query those.

This is mirrored in the Ace3 initialization scheme as well with :OnInitialize() corresponding to ADDON_LOADED for our addon, and :OnEnable() corresponding to PLAYER_LOGIN.

Many authors got into the habit of doing initialization on PLAYER_LOGIN since it was assumed (and for a very long period of time actually worked like that) that it always fires later than ADDON_LOADED.

This is no longer the case and PLAYER_LOGIN can fire earlier in the loading process than ADDON_LOADED for 'our addon' on some systems or for the same player from login to login.
This last statement should not be the case, and I've never actually seen this happen. PLAYER_LOGIN should never occur prior to the ADDON_LOADED for any AddOn which is not Load on Demand.

For Load on Demand AddOns, all bets are off.
__________________
"Never mistake ignorance for stupidity. Ignorance is curable; stupidity is not." - Unknown
  Reply With Quote
10-01-13, 04:39 PM   #10
Dridzt
A Pyroguard Emberseer
 
Dridzt's Avatar
AddOn Author - Click to view addons
Join Date: Nov 2005
Posts: 1,359
Originally Posted by Esamynn View Post
I know I'm late to the party here, but I just can't leave this alone.



This last statement should not be the case, and I've never actually seen this happen. PLAYER_LOGIN should never occur prior to the ADDON_LOADED for any AddOn which is not Load on Demand.

For Load on Demand AddOns, all bets are off.
I can't reliably reproduce it (the behavior varies between cold-login and /reload or log to character selection) but I've definitely seen it happen and I'll watch for it, report it here when I catch it again.
  Reply With Quote

WoWInterface » AddOns, Compilations, Macros » AddOn Help/Support » SetFont errors in 5.4

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off