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)
|
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
|
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. |
3 Attachment(s)
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. |
Well... you would be in this loop...
Code:
for unit_name in pairs( layout_config.elements.units ) do |
2 Attachment(s)
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.
Code:
frame.applySkin = function( skin ) 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 .. Code:
-- apply the current skin 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. |
2 Attachment(s)
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. |
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. |
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. : Code:
local function AddonLoaded(event,...) |
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. |
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. |
This is where I have been getting the information that prompted looking into things further.
http://www.wowwiki.com/Events_that_f...oading_Process Quote:
|
4 Attachment(s)
Okay, removed all addons except my testing one to give the chat frame a clear run at messages without the other addon spiel :D
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. |
Chat Frame Issues
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) |
Quote:
I'll work on it this weekend and get another update out... should be the final fix for it. /yaay |
For the record... it appears you cannot count on the PLAYER_ALIVE event. If you do a '/nui rl' it does not fire.
|
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 :D
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. |
Quote:
|
Quote:
|
All times are GMT -6. The time now is 07:08 PM. |
vBulletin © 2024, Jelsoft Enterprises Ltd
© 2004 - 2022 MMOUI