Originally Posted by sirinsidiator
I feel like I am talking against a wall again... You still don't seem to understand that ESO already actively not loads duplicates. When you have version 1 and version 2 of "SomeAddon" in different subfolders of your addon folder, only SomeAddon v2 is loaded by the game. There is no need for any code written by the addon author to prevent v1 from loading, since the game already takes care of that. That's exactly the reason why we need to get rid of LibStub, because LibStub is not capable of doing that.
|
No walls, sirinsidiator, just a misunderstanding and some miscommunication between us. I do understand that ESO already does not load duplicates. That is not my issue. My point is that, what ESO does not do is to actively reject embedded folders that contain duplicate add-ons, nor does ESO provide an option to select whether we want to process and accept or reject duplicate folder packaging!
What I am trying to do is to eliminate the poor packaging and the substandard code that lets duplicate folders remain in poorly constructed and/or maintained add-on packages. Right now, for example, I use a stand-alone LibStub on PTS as a test bed to load my libraries. It is the only copy of LibStub in my PTS system and all my libraries share it. It works.
Problems arise, however, whenever my libraries use other developer's libraries and those other libraries contain unneeded and unnecessary, duplicate LibStub folders that those developers embedded to load their libraries. This folder duplication is not an issue, per se, because their add-ons also load and work so that is not the focus of my efforts.
My complaint is that processing these duplicate folders and their manifests only to dump their add-ons as duplicates wastes time and resources that could be better spent loading additional add-ons. If we could eliminate processing these duplicate folders, we would probably speed up starting the game, or "zoning", or anytime anything triggers an internal "/reloadui" event and we would probably reduce the possibility of add-on load failures or run-time errors as an additional bonus.
My irritation is that embedded folders often break loading my add-ons because their add-on developers "forgot" to maintain or replace an embedded add-on folder. I refer to this as an irritation only because I do it to myself all to often.
What I am trying to do within the stand-alone environment is to create a methodology for loading stand-alone add-ons that provides us developers (and ESO) with the option to accept or reject duplicate add-ons and their embedded folders. I think I may have succeeded. I shall be passing the latest LoadAddon stub by you and the other add-on developers for comments and critiques soon.
Originally Posted by sirinsidiator
It is true that you cannot retrieve the value from the manifest file, but you can simply copy the number you put in the manifest into any of your Lua files and you have EXACTLY the number you want with no guessing involved, since the game makes sure that only one version of your addon is loaded when you specify the AddOnVersion in the manifest. I repeat again, there is no uncertainty that the number you have in your code is the same as the one in the manifest when you take care that you update it in both the txt and lua file.
|
And what happens when someone else modifies the AddOnVersion value in the manifest file of their copy of my add-on? Right! Suddenly, ESO refuses to load my add-on because "my" AddOnVersion number has become older than the ESO version. Since I have no access to the current ESO AddOnVersion value, I have to keep "guessing" at values until I find a randomly, larger number that works!
And what if some malicious, piece of work changes the AddOnVersion value in their manifest file to 2,147,483,647? There is no larger value that I can use to recover! Then what can I do? What would you do? Or what would ESO do should the same thing happen to one of our add-ons? Or to one of theirs, for that matter?
That is why I think "guessing" at AddOnVersion values is an incomplete approach to implementing version controls.
Last, I appreciate your patience and persistence, sirinsidiator. I learn something every time we engage in one of these discussions. And even should the effort I spent developing the LoadAddon stub prove to have been wasted effort on my part, I still will have learned something. I thank you.