ESOUI - [implemented] api version variable in addon manifest

Page 1 of 3

Show 60 post(s) from this thread on one page

ESOUI (https://www.esoui.com/forums/index.php)

- Wish List (https://www.esoui.com/forums/forumdisplay.php?f=177)

- - [implemented] api version variable in addon manifest (https://www.esoui.com/forums/showthread.php?t=4894)

sirinsidiator

07/15/15 04:22 PM

[implemented] api version variable in addon manifest

I was just wondering if it would be possible to add a new variable for the addon manifest so that we can make the addon compatible for both api versions on a major patch without having to clutter the code with

Lua Code:

if(GetAPIVersion() == 100011) then 
--old 
else 
--new 
end

Something like

Code:

Startup_${apiversion}.lua

which then loads either Startup_100011.lua or Startup_100012.lua depending on the api version.

Fyrakin

07/15/15 11:12 PM

Quote:

Originally Posted by sirinsidiator (Post 22033)

Lua Code:

if(GetAPIVersion() == 100011) then 
--old 
else 
--new 
end

Something like

Code:

Startup_${apiversion}.lua

which then loads either Startup_100011.lua or Startup_100012.lua depending on the api version.

Well, api version never goes backwards on live, you would have to remove the redundant file with the next add-on update anyway. I see no problems having add-on tested and prepared on PTS and updated once patch went live.

sirinsidiator

07/16/15 02:28 AM

Of course you will remove the old version once it is no longer necessary, but there is also the delay in the update between EU and NA server to think about. That way you could easily upload a version that is compatible with both APIs and make the transition as smooth as can be.
Also it can't hurt to have the addon ready and published for the PTS so people can test your changes beforehand and instead of making a separate addon I would prefer to just have a version that is compatible with both.

Even without this feature I will find a way to do it, but it would be much cleaner this way, because no unnecessary code is loaded.

Randactyl

07/16/15 09:51 AM

Quote:

Originally Posted by sirinsidiator (Post 22037)

Also it can't hurt to have the addon ready and published for the PTS so people can test your changes beforehand and instead of making a separate addon

Stop, stop! I can only become so erect. This would be awesome :banana:

ZOS_ChipHilseberg

07/17/15 09:24 AM

I went ahead and added an {APIVersion} variable that is substituted with the current version in any paths listed in the addon ToC. I'll try to make a case for this for the next update (2.1).

sirinsidiator

07/17/15 12:47 PM

Thank you very much! That will come in really handy in the future. :banana:
Will this go into one of the next incremental patches, or what else will the variable resolve to in the current live version in case it only makes it into update 2.1?

And just out of curiosity, are there any other substitutions besides ${language}?

ZOS_ChipHilseberg

07/27/15 09:39 AM

This change is slated for the new incremental live patch.

ZOS_ChipHilseberg

07/27/15 11:07 AM

The result of all this will be with the first patch to PTS (not the launch of it) you will be able to type $(APIVersion) in file paths and have it substitute in the API version on both PTS and live.

ZOS_ChipHilseberg

07/27/15 11:50 AM

Quote:

And just out of curiosity, are there any other substitutions besides ${language}?

The only other valid one is $(languageDirectory)

sirinsidiator

07/29/15 07:23 AM

There is no way to see what a resolved path will look like, right?
${languageDirectory} sounds like it would resolve to "en/"?
Something like

Code:

string resolvedPath = DebugResolveAddonPath(string manifestEntry)

could help with debugging path issues.

Or maybe even add some new functions to AddOnManager so we can build a panel that shows which files are loaded or not loaded and in which order.

Code:

integer numFiles = AddOnManager:GetNumAddOnFiles()

integer addonIndex, string resolvedPath, bool wasLoaded = AddOnManager:GetAddOnFileInfo(integer fileIndex) -- fileIndex reflects the loading order

votan

08/13/15 03:57 AM

If an addon is multi api version ready, how to specify supported versions so it does not be shown as "out-dated" for one of the clients?
## APIVersion: 100011 100012
or
## APIVersion: 100011
## APIVersion: 100012
?

What happens, if someone tries
## APIVersion: ${apiversion}

/edit:
tried myself:
None of it works. => Once a new api version goes live, one still has to update the addon manifest for those who can't do that on their own.
May I did not get, what it's good for?!? :o

circonian

08/14/15 03:58 PM

I don't think it marks higher versions as out of date.

So can't you just put the higher version number:

Lua Code:

## APIVersion: 100012

Then it will not show out of date for 100011 or 100012. I'm pretty sure I did that once before when publishing changes before the patch and it worked.

votan

08/14/15 04:05 PM

Quote:

Originally Posted by circonian (Post 22677)

I don't think it marks higher versions as out of date.

So can't you just put the higher version number:

Lua Code:

## APIVersion: 100012

Then it will not show out of date for 100011 or 100012. I'm pretty sure I did that once before when publishing changes before the patch and it worked.

Unfortunately it does. :(
100012 is "out-dated" for a 100011 client. At least for my EU client.

circonian

08/14/15 04:45 PM

I must remember wrong. I probably just posted it early with the new api version and let it show out of date until the patch.

circonian

08/14/15 05:27 PM

edit: Removed due to error.

sirinsidiator

08/15/15 10:43 AM

@circonian: I don't think that would help, because the addon gets disabled before the game loads if the "allow out of date addons" checkbox is not checked, so it would only be cosmetic.

Listing multiple versions like in votan's post sounds like a good solution IMHO. Just because it is compatible with a newer API version does not mean it is compatible with the old one... not that it would matter once the new version has been released though. :D

Btw, has anyone gotten the new variable expansion to work?
I tried several ways but it does not load the file on live or pts.
Writing

Code:

test/test_100011.lua

does load the file without a problem, but none of these do work for .lua or .xml:

Code:

test_${APIVersion}/test.lua

test_${apiversion}/test.lua

test_{APIVersion}/test.lua

test_{apiversion}/test.lua

test/test_${APIVersion}.lua

test/test_${apiversion}.lua

test/test_{APIVersion}.lua

test/test_{apiversion}.lua

test_${APIVersion}.lua

test_${apiversion}.lua

test_{APIVersion}.lua

test_{apiversion}.lua

Am I missing something here?

merlight

08/15/15 10:47 AM

Round braces, not curly ;)

sirinsidiator

08/15/15 11:28 AM

I blame it on the xml. :o

circonian

08/15/15 07:08 PM

Quote:

Originally Posted by sirinsidiator (Post 22688)

@circonian: I don't think that would help, because the addon gets disabled before the game loads if the "allow out of date addons" checkbox is not checked, so it would only be cosmetic.

Oh your right it gets disabled before, so that code never gets a chance to run. I didn't think of that.

votan

08/19/15 06:46 AM

I have succesfully used it on live and PTS. :banana:
It is case-sensitive and must be written as Chip said: $(APIVersion)
not $(apiversion) or $(ApiVersion)

As you still have to increase the APIVersion in the manifest (and upload a newer addon) after the update goes live, the only scenario I have found is: Creating an intermediate version addon, which does not scramble saved variables due to breaking changes, if the user allows to run "out-dated" addons.

Another drawback compared to GetAPIVersion() is: You can not say APIVersion>=100012, only APIVersion==100012. So again, once the update goes live, you need to upload a new version, which removes the version substitute again, in hope the next API version will not affect your addon, again.

But migration is definitely better as without the substitute.

Thank You, Chip!

All times are GMT -6. The time now is 01:08 AM.

Page 1 of 3

Show 60 post(s) from this thread on one page