Library race condition?
Hello,
So I have a library with functions I use in many of my addons. I set up this library as appropriate, with the ## IsLibrary: true tag and in the ## DependsOn: section of my other addons... EDIT: Figured it out, thanks! |
Were you bundling the lib with your addons for awhile? Did you ever do so without a txt file? If you use DependsOn, it shouldn't matter if it's a library or another addon: yours will be loaded after it. If someone can prove this happens with only MRL and your lib, that's when I'd blame ZOS.
|
Thanks for the quick reply!
Nope, not bundled. Addon is Master Recipe List and library is LibPhinixFunctions. Neither has been changed since they were last uploaded, and were working fine at the time. The only thing that changed is something in a patch between then and now. I have been away from the game for months and only came back to update as people were pointing out the sudden errors related to nil returns from a library that the addon is set to depend on. EDIT: Problem was unrelated to addon dependency loading. Recipes in the MRL database were removed from the game in a recent patch requiring the database to be edited so reference to these no longer existing ID's didn't cause errors. The other thing with the library was a syntax typo that just happened to happen at the same time, causing me to jump the gun on the suspected cause. :) |
Maybe I've just been lucky so far. None of my addons have had such an issue flagged.
Not ideal and I'm not sure if it would work but: you must be using such a function on load for it to be causing an error? By the time a player would get to a prov station, open their inventory, etc. the lib would be loaded regardless of order. Instead of the addon load event immediately initializing the addon, what about doing a lib check first and if the lib is nil, use a call later to retry your init X seconds later, repeating until the lib is finally loaded. |
We are talking about this error, right?
Code:
user:/AddOns/MasterRecipeList/MasterRecipeList.lua:2430: operator .. is not supported for nil .. string The line in question contains this code: Lua Code:
The only things concatenated here are "known", the return value of "pTC", "catstring" and "preview". The three local variables show up in the variable list below the line in the stack trace, so they are definitely not nil, which leaves only the return value of pTC. From what I see pTC refers to the function TColor in LibPhinixFunctions and the code looks like this: Lua Code:
The remaining question is, why is color nil? from what I see in the code it should be the return value of GetItemLinkQuality converted to a color string via a lookup table. From the item name we can deduce that the link in question is |H1:item:118299:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0|h|h which should return a quality of 5 and result in a color string of "eeca2a", but for some reason that's not the case here. |
I thought the same some weeks ago Phinix.
Somehow I had erros which only happened if I tried to access the libraries at the beginning of my first loaded lua file in my addon. The txt file had the library as ## DependsOn: so I thought all will be fine and the lib will be definately loaded BEFORE my addon's lua file is executed. But sometimes it was working differently. Just coulnd't track down when. As the lib was included into other addons (LibMainMenu) and even called hardcoded without ttx file I assumed it was somehting the other addons caused, cuz they don't use and txt file and DpendsOn tag. I also told sirinsidiator about it and asked if it would make a difference if I move the libs "first" call in my lua file to my callback function of event_add_on_loaded, or if it is directly at teh start of the lua file. He said it makes no difference as the ## (Optional)DependsOn handles the load of the library files properly before my lua file is loaded IF the lib got its own txt file and was added to my addon's ## DependsOn: tag. All was setup properly, but I still got some error messages in the chat sometimes. So I decided to move the lib stuff to the event_add_on_loaded callback function and since then the errors stopped. Might have been another addon or bad code somewhere. But also might be that there is somethign broken at the ZOs stuff of the dependencies under some circumstances... Btw: This only happend with LibMainMenu for me so far so I really think it's because of other addons trying to access the lib to early. After cleaning up my addons and removing hardcoded lib calls most erros were gone as the addons were using the most up2date libraies directly from the AddOns directory, laoding them properly with their txt files. So meanwhile I'd say it's not a general problem but related to the lib's loading and missing txt files, or wrong code somwhere. @sirinsidiator: pTC refers to the function TColor of LibPhinixFunctions. I can't find that in the list of the traceback? So it might also be that pTC is just nil here cuz the lib LibPhinixFunctions function TColor is tried to be accessed before the library was loaded? |
Quote:
|
@sirinsidiator - Thanks for taking a look.
EDIT: May have worked it out, testing... |
Quote:
Lua Code:
|
Thanks Scoot, is that new? I remember not finding that in the ESOUI function database on UESP back in the day. :)
Also I think I might have figured it out... Some of the recipes in the current MRL database may have been since removed from the game and so looking up their quality level is returning nil. The other thing I posted appears to be a separate issue and maybe resolved, will update... |
Quote:
|
Last major update removed a huge number of blueprints, so that would be a reasonable source for nils from links you were constructing via an internal list of ids.
|
Quote:
|
@Rhyono yep that is definitely it. :)
The other library errors I was getting turned out to be just me being rusty and messing up the syntax while converting away from LibStub (used ':' instead of '.' as a constructor between the global library table and the function definition, adding an extra 'self' variable to them all and throwing off the values. DOH! @sirinsidiator you were correct, dependency checking had nothing to do with it! |
All times are GMT -6. The time now is 04:32 PM. |
vBulletin © 2024, Jelsoft Enterprises Ltd
© 2014 - 2022 MMOUI