new error on login

[spiel2001]

Xrystal... can you check your error logs in the WoW log directory and see if they have any error messages recorded for that error? (with 5.6.14)

[tinyu]

when i upgraded to this latest version i deleted my old nUI folder before i copied the new one id say give that ago cause mines working fine... atm

[Xrystal]

I'll check next time it happens Scott. The log is already reset to the new session which is fine.

And just logged in now on anothing character and there is no error.

And yeah tinyu, I do the same. I rename or move the old nUI folder and copy the new one in. Although I don't always reset the WTF nUI files.

[Xrystal]

Well, been checking the error logs and no luck on showing anything remotely nuiish.

However, I did some debugging and I noticed that it doesn't get into :

nUI_Unit.lua - function nUI_Unit:createUnit( name, parent, options )

I am guessing that is the start of filling out the player frame and then your party and raid frames if and when they occur ?

Well, put a debug message on the first line in that function and it never prints. However, assuming that the script files load in order when listed in the xml file the file that would load up before then would be the nUI_Hud.lua file. I placed 5 debug messages in the onHUDLayoutEvent and they all fired in the order expected.

So a brief list of execution:

onHUDLayoutEvent
-- message 1
.. PlayerLogin
.. -- message 4
.. .. Executed code
.. -- message 5
-- message 1
.. Variables Loaded
.. -- message 2
.. -- Executed code
.. -- mesage 3

Whatever code happens next ....

nUI_Unit.lua - nUI_Unit:createUnit( name, parent, options )
No message appears

But I see it is called from nUI_Hud so sounds like there could be the problem .. debugging some more.

Okay, in nUI_Hud debug printing in newUnitInfo showed as working through it .. so so far so good.

sigh, running out of characters it is bugging out on rofl ..

okay, put debug code in applyskin function of nUI_HUD.lua and the bugged out screen happens when that code doesn't execute.. time to check an earlier block somewhere rofl.

okay, looks like somewhere between the event for VariablesLoaded and the applyskin function is called in nUI_hud.lua is where the problem is.

Alrighty. think I am stuck on more testing until I know what appears between those functions but here are two screenshots showing the debug function messages with and without the error occuring. Hopefully Scott, you can give me an idea on what to debug through next to narrow it down more rofl.

[spiel2001]

Well... you would be in this loop...

                        for unit_name in pairs( layout_config.elements.units ) do
                            
                            local options = layout_config.elements.units[unit_name].options;
        
                            -- if the unit already exists and the option is not enabled, then
                            -- disable the frame
                            
                            if not options.enabled then
                                
--                                nUI:debug( "nUI_HUD: unit [ "..unit_name.." ] is disabled", 1 );
                                if hframe.Elements[unit_name] then
                                    hframe.Elements[unit_name].setEnabled( false );
                                end
                            
                            -- otherwise, if the unit does not exist yet, create it
                            
                            elseif not hframe.Elements[unit_name] then
                                
--                                nUI:debug( "nUI_HUD: creating unit [ "..unit_name.." ]", 1 );
                                hframe.Elements[unit_name] = nUI_Unit:createUnit( unit_name, options.fade and hframe.fader or hframe, options );
                                
                            -- and if it does exist, then update the skin and make sure
                            -- the unit is enabled
                            
                            else
                                hframe.Elements[unit_name].applyOptions( options );
                                hframe.Elements[unit_name].setEnabled( true );
                            end
                        end

This is in nUI_HUD.lua -- it was in the process of creating the units for the HUD but did not finish. So, either it died before returning from the createUnit method or in this loop itself. That narrows it down pretty well. Adding a print message in return from CreateUnit() would clarify which.

[Xrystal]

Hmm, I'll try it but I have debug code at the top of the applyskin function and that doesn't execute so it doesn't even get that far to test the block you showed.

frame.applySkin = function( skin )
	
--	nUI_ProfileStart( ProfileCounter, "applySkin" );
	
	-- we don't allow the skin developer to not include HUD layouts... if they
	-- don't specify them, we use the default
	print("1. nUI_Hud: applySkin : ", skin);
	local skin = skin.HUDLayoutSelector or nUI_DefaultConfig.HUDLayoutSelector;
	
	if not skin or not skin.options.enabled then
		
		frame.enabled = false;
		background:Hide();
		
	else
		
		local have_selection   = false;
		local rotation         = {};
		local buttonbag_states = nil;
		
		frame.enabled = true;
		background:Show();

		frame.applyOptions( skin.options );
		frame.applyAnchor( skin.anchor );

		-- parse the list of available panels.
		
		for layout_name in pairs( nUI_HUDLayouts ) do
	
			local layout_config = nUI_HUDLayouts[layout_name];
			local layout_info   = nUI_HUDLayoutSelector.Layouts[layout_name];
			
			-- if it the layout is diabled, then make sure it's not longer visible
			-- or in the rotation

As you can see the debug message should execute the moment it hits the function but it doesn't when that error occurs.

And seeing as this seems to call the applyOptions and applyAnchor it looks like I need to find out what calls applySkin and debug back from there but every file has an applyskin but nothing seems to call it from what I can see. Ah found 2 blocks of applySkin codes. 1 in nUI.lua and 1 in nUI_Unit.lua.. might help track it down further.


edit 1:
Well, looks like I found something interesting ..

		-- apply the current skin
		print("nUI.lua - Skinning Frames...");
		for i=1, #nUI.SkinnedFrames do
			print("Skinning Frame ", i);
			nUI.SkinnedFrames[i].applySkin( nUI_CurrentSkin );
		end

When it errors out the for loop isn't executed which signifies that the skinned frames list isn't being created. This block of code is in the PlayerLogin event which I believe can happen before VariablesLoaded sometimes if I remember rightly which is the other event in use in the nUI.lua file.

Edit 2 : Interesting. Yep, seems to be a load order problem so far. sometimes it tries to skin the frames before the list is created and other times it creates the list before the frames are skinned so no problems. 2 more screenshots.

[Xrystal]

Okay, and just so it wasn't a fluke the other times. I have refined the error messages and can confirm the sequence of events are what are messing things up.

if PLAYER_LOGIN is triggered last it will load properly. If VARIABLES_LOADED is triggered last it will load bad.

The unfortunate solution is to use ADDON_LOADED to do data preparation and PLAYER_LOGIN for displaying etc and VARIABLES_LOADED to override positioning and anchoring that blizzard sets up from their variables.

And the reason there is no error message is because nothing is going wrong. A for loop will just not execute if there are no items in the list and so thus the tests later on silently fail.

But then thats my theory.

[spiel2001]

Wow... so PLAYER_LOGIN is actually firing before the VARIABLES_LOADED event... that explains a lot.

I'll have to look at the code, but I can probably replace the PLAYER_LOGIN event with the PLAYER_ENTERING_WORLD event and get a reliable result.

Does ADDON_LOADED *always* fire after the VARIABLES_LOADED event?

PS: *EXCELLENT* catch Xrystal... and thank you for the time invested in solving it.

[Xrystal]

From what I understand from my tests while reworking my addons is that the order seems to be something along these lines:

ADDON_LOADED - addon's saved variables loaded and ready for use
PLAYER_LOGIN
PLAYER_ENTERING_WORLD


VARIABLES_LOADED - fired whenever blizzard has finished with their saved variables so at any time between ADDON_LOADED and the game actually being ready for use.


Hmm, just looked back at my images and its interesting .. not noticed ADDON_LOADED firing after PLAYER_LOGIN. Unless, those are other addons that are set to load on demand once logged in .. hmm. But then again not every one of your files are testing for the addonloaded event so hard to say for sure. I'll rig up an event lister and see what order they come out at on a regular basis.

I've been reworking my watch frame addon with this loading order in mind and so far I have got this working exactly as expected using this. I have almost got the same functionality of my current version with alot less coding done as I am now not fighting with what blizzard wants to do but working with it. :

local function AddonLoaded(event,...)
	CreateFrames();
end
local function PlayerLogin(event,...)
	ShowFrames();
end
local function VariablesLoaded(event,...)
	SizeFrames();
	PositionFrames();
end

local function OnEvent(self,event,...)
	if ( event == "ADDON_LOADED" and arg1 == addonName ) then
		AddonLoaded(event,...);
	elseif ( event == "PLAYER_LOGIN" ) then
		PlayerLogin(event,...);
	elseif ( event == "VARIABLES_LOADED" ) then
		VariablesLoaded(event,...);
	end
end

local XEvents = CreateFrame("Frame",UIParent);
XEvents:SetScript("OnEvent",OnEvent);
XEvents:RegisterEvent("ADDON_LOADED");
XEvents:RegisterEvent("PLAYER_LOGIN");
XEvents:RegisterEvent("VARIABLES_LOADED");

[spiel2001]

Unfortunately, what frames are created, where and so on are all defined by the saved variables, so I need those before I create the frames or try to anchor them.

So, I have to have the VARIABLES_LOADED event before I do anything. Once I have that, then I can build the UI. PLAYER_ENTERING_WORLD *should* always happen after VARIABLES_LOADED, but I really need one other event that always occurs between VARIABLES_LOADED and PLAYER_ENTERING_WORLD.

[Xrystal]

When you're talking about variables being loaded are you talking about your own or blizzards ?

ADDON_LOADED = your own variables
VARIABLES_LOADED = blizzards

I use addon_loaded to carry out the initialisation of the frames and then finalise the positions and sizes in variables_loaded after blizzard has done their stuff with the frames. I noticed that they have their own layout-cache file that stores sizes and positions of many frames which overrode the layout I had loaded from my variables. So I reposition all my frames then to override their changes.

[Xrystal]

This is where I have been getting the information that prompted looking into things further.

http://www.wowwiki.com/Events_that_f...oading_Process

Saved variables loading After the addon code has been loaded, the loading process can be followed by registering for various events, listed here in order of firing. 1.ADDON_LOADED This event fires whenever an AddOn has finished loading and the SavedVariables for that AddOn have been loaded from their file. 2.SPELLS_CHANGED This event fires shortly before the PLAYER_LOGIN event and signals that information on the user's spells has been loaded and is available to the UI. 3.PLAYER_LOGIN This event fires immediately before PLAYER_ENTERING_WORLD. Most information about the game world should now be available to the UI. All Sizing and Positioning of frames is supposed to be completed before this event fires. AddOns that want to do one-time initialization procedures once the player has "entered the world" should use this event instead of PLAYER_ENTERING_WORLD. 4.PLAYER_ENTERING_WORLD This event fires immediately after PLAYER_LOGIN Most information about the game world should now be available to the UI. If this is an interface reload rather than a fresh log in, talent information should also be available. All Sizing and Positioning of frames is supposed to be completed before this event fires. This event also fires whenever the player enters/leaves an instance and generally whenever the player sees a loading screen 5.PLAYER_ALIVE This event fires after PLAYER_ENTERING_WORLD Quest and Talent information should now be available to the UI Until 3.0, VARIABLES_LOADED used to fire upon completion of the addon loading process; since 3.0, it is fired in response to CVars, Keybindings and other associated "Blizzard" variables being loaded, and may therefore be delayed until after PLAYER_ENTERING_WORLD. The event may still be useful to override positioning data stored in layout-cache.txt [edit] Load On Demand behavior Load on Demand addons cannot rely on most of the event sequence being fired for them; only ADDON_LOADED is a reliable indication that the saved variables for your LoD addon have been loaded.

[Xrystal]

Okay, removed all addons except my testing one to give the chat frame a clear run at messages without the other addon spiel

Screen Shot 1 : Fresh Log In from Desktop
Screen Shot 2 : Reload UI
Screen Shot 3 : Log Out to Character Selection and Back In again
Screen Shot 4 : Log Out to Character Selection, toggle through characters and Back In on same character again ...

As you can see the Variables Loaded event is very unreliable to do all the work in.

[mpsurge]

Issue I have is with Chat Frames. Once reset, login onto WoW default interface, restart game, all is well OR all is well with exceptions. Like the chat window not loading properly.

I do have other Addons, as you will see, but disabling them [using nUI only] makes no difference.

Also, this problem only gets caught once. All subsequent "mis-loads" do not show as errors.

This also effects the menu area at top and mini-map as well.

Date: 2010-04-30 12:02:46
ID: 1
Error occured in: Global
Count: 1
Message: ..\FrameXML\FloatingChatFrame.lua line 1061:
ChatFrame1:SetPoint(): trying to anchor to itself
Debug:
[C]: ?
[C]: SetPoint()
..\FrameXML\FloatingChatFrame.lua:1061:
..\FrameXML\FloatingChatFrame.lua:1050
...ace\AddOns\Blizzard_CombatLog\Blizzard_CombatLog.lua:3506: FCF_DockUpdate()
..\FrameXML\FloatingChatFrame.lua:1307: FCF_Close()
..\FrameXML\FloatingChatFrame.lua:73: FloatingChatFrame_Update()
..\FrameXML\FloatingChatFrame.lua:36: FloatingChatFrame_OnEvent()
[string "*:OnEvent"]:2:
[string "*:OnEvent"]:1
AddOns:
Swatter, v3.1.14 (<%codename%>)
AucAdvanced, v5.8.4696 (CreepyKangaroo)
AucFilterBasic, v5.8.4696 (CreepyKangaroo)
AucFilterOutlier, v5.8.4696.2531
AucMatchUndercut, v5.8.4696.2531
AucStatHistogram, v5.8.4696 (CreepyKangaroo)
AucStatiLevel, v5.8.4696 (CreepyKangaroo)
AucStatPurchased, v5.8.4696 (CreepyKangaroo)
AucStatSales, v5.8.4696.2842
AucStatSimple, v5.8.4696 (CreepyKangaroo)
AucStatStdDev, v5.8.4696 (CreepyKangaroo)
AucStatWOWEcon, v5.8.4696.2530
AucUtilAHWindowControl, v5.8.4696.3311
AucUtilAppraiser, v5.8.4696.2530
AucUtilAskPrice, v5.8.4696.3175
AucUtilAutoMagic, v5.8.4696.3142
AucUtilCompactUI, v5.8.4696.2530
AucUtilEasyBuyout, v5.8.4696.3583
AucUtilFixAH, v5.8.4696 (CreepyKangaroo)
AucUtilGlypher, v5.8.4696.2545
AucUtilItemSuggest, v5.8.4696.3108
AucUtilPriceLevel, v5.8.4696.2545
AucUtilScanButton, v5.8.4696.2530
AucUtilScanFinish, v5.8.4696.3576
AucUtilScanProgress, v5.8.4696.2530
AucUtilScanStart, v5.8.4696.2530
AucUtilSearchUI, v5.8.4696.3655
AucUtilSimpleAuction, v5.8.4696.4546
AucUtilVendMarkup, v5.8.4696.2530
Babylonian, v5.1.DEV.130
BeanCounter, v5.8.4696 (CreepyKangaroo)
BloodyRare, v1.5
Carbonite, v3.33
CarboniteTransfer, v1.01
Configator, v5.1.DEV.130
DebugLib, v5.1.DEV.130
Enchantrix, v5.8.4696 (CreepyKangaroo)
EnchantrixBarker, v5.8.4696 (CreepyKangaroo)
Gatherer, v3.1.14
GathererDBWowhead, v1.0.2009-12-09
Informant, v5.8.4696 (CreepyKangaroo)
nUI, v5.06.15 (Plus)
nUIStone, v1.02.00
Postal, v3.3.1
SlideBar, v3.1.14 (<%codename%>)
Stubby, v5.8.4696 (CreepyKangaroo)
Titan, v4.3.4.30300 - Revision 345
TitanAmmo, v4.3.4.30300
TitanBag, v4.3.4.30300
TitanCarbonite, vv3.3
TitanClock, v4.3.4.30300
TitanCoords, v4.3.4.30300
TitanGatherer, v3.3.3
TitanGoldTracker, v4.3.4.30300
TitanLogout, v1.3.0
TitanLootType, v4.3.4.30300
TitanMount, v1.00.30000
TitanPerformance, v4.3.4.30300
TitanProfessions, v3.3.3
TitanRecZone, v3.0.6
TitanRegen, v4.3.4.30300
TitanRepair, v4.3.4.30300
TitanVolume, v4.3.4.30300
TitanXP, v4.3.4.30300
BlizRuntimeLib_enUS v3.3.3.30300 <us>
(ck=858)

[spiel2001]

Originally Posted by Xrystal As you can see the Variables Loaded event is very unreliable to do all the work in.

That's awesome info Xrystal and explains much... I didn't realize that was how they changed it which would explain why it's been borked since that ADDON_LOADED change was made. Now I "understand" what the implications of that were.

I'll work on it this weekend and get another update out... should be the final fix for it.

/yaay

[spiel2001]

For the record... it appears you cannot count on the PLAYER_ALIVE event. If you do a '/nui rl' it does not fire.

[Xrystal]

yep, another one that doesn't seem to trigger all the time .. PLAYER_LOGIN or PLAYER_ENTERING_WORLD seem to be the last you should count on and ADDON_LOADED as the first .. anything between and after are down to pure chance

And with the amount of files you have in nUI I won't be surprised if this change takes ages to do as you will probably need to be consistent in all the files that use the event system.

[Rilgamon]

Originally Posted by Xrystal yep, another one that doesn't seem to trigger all the time .. PLAYER_LOGIN or PLAYER_ENTERING_WORLD seem to be the last you should count on and ADDON_LOADED as the first .. anything between and after are down to pure chance

And I thought I was just too stupid to do it right ... I can confirm your findings

[Xrystal]

Originally Posted by Rilgamon And I thought I was just too stupid to do it right ... I can confirm your findings

Rofl, the secret of debugging code .. insert print statements at key points and see if they appear. If not, then the code isn't getting that far. Step back and try again. Fortunately I started on the last 2 files in the execution line. Would have taken a lot longer to find it if I started from the top