[implemented] api version variable in addon manifest

[sirinsidiator]

I updated the addon manifest wiki page a few days ago and added a dedicated section about variables. Maybe we should mention somewhere that it is case sensitive?
I am also still not sure what $(languageDirectory) expands to. Chip didn't answer my question about it and it is not used anywhere in the UI code.

[merlight]

Originally Posted by sirinsidiator I updated the addon manifest wiki page a few days ago and added a dedicated section about variables. Maybe we should mention somewhere that it is case sensitive? I am also still not sure what $(languageDirectory) expands to. Chip didn't answer my question about it and it is not used anywhere in the UI code.

I ran ESO with WINEDEBUG=file, thinking I'd be able to see what file it tries to open when I have missing/$(languageDirectory)/file in manifest, but no luck. Apparently ESO uses FindFirst/NextFile "*.*" to scan the whole add-on directory, then reads the manifest, replaces the variable and only opens files it has already found.

[circonian]

All of the localization.txt files use it. Is it something compiled that we don't have access to?

pregamelocalization.txt

EsoUI\PregameLocalization\LocalizePregameGeneratedStrings.lua
$(languageDirectory)\lang\$(language)_pregame.lua

[sirinsidiator]

Ah. I had only *.lua and *.xml set in my search filter.

$(languageDirectory)\lang\$(language)_pregame.lua

It seems to refer to this file:

\esoui\lang\en_pregame.lua

I guess it expands to "esoui" then?

please Chip, could you look into adding a support for multiple valid API to accompany this marvelous variable?
with a syntax like votan tried, a long long time ago :

Originally Posted by votan ## APIVersion: 100011 100012 or ## APIVersion: 100011 ## APIVersion: 100012

That way we would be able to upload only once before the patch as soon as it's tested on PTS if we want to, and there wouldn't be any downtime between NA and EU patches too. And stay under authors control too.

Thank you very much.

[Ayantir]

+1 for this, with big addons, I often have a comment saying that the addon isn't functionnal the D-Day because EU users are updating too quickly.

And for some addons, I cannot really wait EU users because NA ones are totally lost without their modified UI.

Those values will tell AddonManager the API compliance of the code, avoiding the out-of date state at each API bump, linked with $(Apiversion) it will help a lot to anticipate changes.

[sirinsidiator]

Yes please. Without that, the added APIVersion variable is only half as useful as it could be.

[dopiate]

Originally Posted by sirinsidiator Yes please. Without that, the added APIVersion variable is only half as useful as it could be.

We talked about multiple variable API's in Fast API.

Do you not want it to support that anymore?

It was in my list of things to do.

Let me know,
-d

We discussed it here and I had planned to implement it.

[sirinsidiator]

Originally Posted by dopiate We talked about multiple variable API's in Fast API. Do you not want it to support that anymore? It was in my list of things to do. Let me know, -d We discussed it here and I had planned to implement it.

I know and I will still use FastAPI as long as there is no better solution available.
That being said, the game itself supporting multiple API version in the addon manifest is something that should have been available all along and I would like to see it becoming a reality.

[dopiate]

Originally Posted by sirinsidiator I know and I will still use FastAPI as long as there is no better solution available. That being said, the game itself supporting multiple API version in the addon manifest is something that should have been available all along and I would like to see it becoming a reality.

I completely agree but since it doesn't I figured this will work for now.

I'm going back over all your PM's and my notes and if you are interested I can send you betas for testing if you want.

Just looking over the code now.

-d

[merlight]

I don't use Minion myself, but I think most of these issues would disappear if it utilized the compatibility field that's attached to each uploaded add-on. Once you start adding/fixing stuff that's on the PTS, you'd simply uncheck compatibility with Live, and Minion wouldn't install it because it would require a higher game version. This would also gracefully work during the period when NA and EU have different game versions.

Originally Posted by merlight I don't use Minion myself, but I think most of these issues would disappear if it utilized the compatibility field that's attached to each uploaded add-on. Once you start adding/fixing stuff that's on the PTS, you'd simply uncheck compatibility with Live, and Minion wouldn't install it because it would require a higher game version. This would also gracefully work during the period when NA and EU have different game versions.

it's not about getting the right file since we can achieve that with $(APIversion) now, it's about not having to re-upload the same file with a new manifest to get rid of the out-of-date tag when the right file is already in use.

[dopiate]

Originally Posted by merlight I don't use Minion myself, but I think most of these issues would disappear if it utilized the compatibility field that's attached to each uploaded add-on. Once you start adding/fixing stuff that's on the PTS, you'd simply uncheck compatibility with Live, and Minion wouldn't install it because it would require a higher game version. This would also gracefully work during the period when NA and EU have different game versions.

You can see what I'm doing here..

-d

[merlight]

Originally Posted by Wandamey it's not about getting the right file since we can achieve that with $(APIversion) now ...

.. until the APIVersion changes and your addon breaks for no other reason than that a meaningless number changed. $(APIVersion) in manifest is probably the second worst solution to the problem.

Originally Posted by Wandamey ... it's about not having to re-upload the same file with a new manifest to get rid of the out-of-date tag when the right file is already in use.

Instead, you have to re-upload the same file with a new name when APIVersion changes again.

This is exactly what I meant by "most of these issues would disappear" -- you wouldn't have to re-upload anything if Minion only installed add-ons compatible with the installed version of the game.

[merlight]

Originally Posted by dopiate You can see what I'm doing here.. -d

I appreciate the effort, and like it for the fact that it's a hack. But it should be an integral part of a proper add-on manager.

Originally Posted by merlight .. until the APIVersion changes and your addon breaks for no other reason than that a meaningless number changed. $(APIVersion) in manifest is probably the second worst solution to the problem.

if you are having troubles using this variable, there is a wiki page explaining how to thanks to Sirinsidiator : http://wiki.esoui.com/Addon_manifest_%28.txt%29_format

Instead, you have to re-upload the same file with a new name when APIVersion changes again. This is exactly what I meant by "most of these issues would disappear" -- you wouldn't have to re-upload anything if Minion only installed add-ons compatible with the installed version of the game.

Yet if I had something like this I could upload my already tested on PTS addons with my API var and both APIversions and go on holidays next week. Instead I can't, even if I'm finished with all of my homework.

Having this would solve all the problems. Not just most of them. And without even mentionning how easy it is to forget to check the compatibility boxes when uploading and the changes it would require for Dolby. Which I think would be more trouble than just allowing multiple APIversion. But it's just a wild guess.

[dopiate]

Originally Posted by merlight I appreciate the effort, and like it for the fact that it's a hack. But it should be an integral part of a proper add-on manager.

I don't think anyone disagrees with you there.

-d

[sirinsidiator]

Originally Posted by Wandamey if you are having troubles using this variable, there is a wiki page explaining how to thanks to Sirinsidiator : http://wiki.esoui.com/Addon_manifest_%28.txt%29_format

What merlight is referring to is my failure to properly use it in sidWarTools.
It worked as expected for the transition on one update, but I didn't update sidWarTools for a long time and then the next update came along and suddenly there was an error that wasn't there before, because one file was missing.
So the proper way to use it, is to provide the files for the next api version without the use of $(APIVersion) and the old files with it like this:

myAddon.lua
myAddon_$(APIVersion).lua

And inside the file you wrap the code into a function MyAddon.Initialize that gets executed from a third file (e.g. startup).
When launched with the old update, the myAddon_100013.lua is loaded and overwrites the function for the new version and once the new api version is available, myAddon_100014.lua is not found and the version from myAddon.lua is executed instead. It won't suddenly stop working because of a missing file in the future api versions either. Hope this makes it clear.

[merlight]

Originally Posted by sirinsidiator What merlight is referring to is my failure to properly use it in sidWarTools.

Actually I wasn't referring to a particular usage. Having such variable in manifest is inherently broken. Everyone will stop updating their add-ons one day. Why should they all break with the next game update just because a version number increases?

Your suggested "proper" usage shows that the variable is useless. You need to have checks inside both files (edit: okay, redefining functions works, but... ugh), one runs only when API version matches its filename, the other runs only when API version doesn't match the other file's name. So they could just as well be named myAddon_old.lua and myAddon_new.lua. $(APIVersion) is pointless, as long as there are never more than 2 game versions outside.

you would need 2 files only for a tricky transition (DB rebuilds that sort of things), and return to one file once it's done, but you could wait a bit to see if there are for some bug reports before releasing the "tested" version in that situation.

And using one only file doesn't lessen the usefulness of a multiple APIversion. It's just about the rush, the mistake we make while uploading several files in a row... (you never forgot to change the folder ? ). That would be way more comfortable. Also, releasing early allow other authors to check the compatibility on PTS etc...