[implemented] api version variable in addon manifest

sirinsidiator · 07/15/15, 04:22 PM

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

Originally Posted by sirinsidiator

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.

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

Originally Posted by sirinsidiator

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

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.

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

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?!?

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

Originally Posted by circonian

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.

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.

circonian · 08/15/15, 07:08 PM

Originally Posted by sirinsidiator

@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.

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!