question about lib and their .txt
 

If A use a lib but modify it for his own addon, without .txt in the lib folder

and this lib is used by b, C, D .... as a Standalone with a different version and a .txt,

which version will be used first by the game ?


-- tried to be clear but not sur, if you need me to ask this differently, let me know lol--

Good question. I couldn't answer definitively (despite what I think it should do) without testing. As a general rule, I don't think anyone should be bundling libraries without their txt file anymore. Or bundling libraries at all, but that's a different matter.

I have actually an addon with this situation, and i wonder if the error if have from it, can come from that or not.

My understanding as a user, was that a standalone lib with the .txt file would always be treated first by the game, so if this lib is different, what to do with their naming or version ?

As stated in the ESOUI wiki Packaging section, Part 1, the game should use the FIRST copy of the library or support add-on it finds that a) has a valid number for its APIVersion: and b) has the highest value (i.e. latest code) in its AddOnVersion: directive.

Translated, this means that the actual selection order (A, b, C, D) that the game uses to find the first copy changes either as the number of add-ons changes or as the add-on names being loaded are changed. However, if either of the APIVersion: or AddOnVersion: directives are missing from the manifest, or have incorrect (e.g. OOD) values in them, then all bets are off and the game either refuses to load the add-on or, if you checked the OOD check box, makes a "best guess" at which add-on to load first.

Rhyono was correct when he said that manifests should not be loading library add-ons by using "libs/mylibrary/mylibrary.lua" commands within their text areas because doing that only makes it more difficult or possibly destroys any chance for the game to find and select the best option from its library add-on choices (A, b, C, or D).

If an add-on refuses to run or the game refuses to load an add-on, you should be able to find the cause by searching for "ERROR" messages in the log files located in the .../Logs/... folder listed below your .../Addons/... folder.

As you have probably surmised by now, loading add-on programs is not trivial and involves complex interactions between the game, the add-ons, and their dependent library and/or support add-ons. If you are interested in learning more about loading add-on libraries, take a look at the forum threads and their links that are linked to this topic and to this obsolete addon.

If the addon is still maintained: the author needs to change it. If they set it up correctly and you have the standalone addon, you could remove the included lib and see if it works.

I will contact the author addons which have the library modified without .txt. - this is a maintenant addon so may be its an error :)

For now the Standalone version of the same addon is used by up to date addons.

THank you

The load order is well defined, but "it's complicated".
Simply put, in case an addon uses an outdated embedded version of a library and doesn't specify the OptionalDependsOn directive in the txt, it is possible for the old embedded version to get loaded before the newer standalone version of the library and as a result cause errors.

Thank you :)

While i was mailing to the author addon libs, and update of the addon just went on, with the right lib in it.

So i guess all is resolved for this addon :)