ESOUI - [outdated] Are any of the strings from an addon's .txt file available within Lua?

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

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

- - [outdated] Are any of the strings from an addon's .txt file available within Lua? (https://www.esoui.com/forums/showthread.php?t=7777)

[outdated] Are any of the strings from an addon's .txt file available within Lua?

Are any of the strings from an addon's .txt file available within Lua?

Specifically, I'd love to reuse some of the strings from WritWorthy.txt:

Code:

## Title: WritWorthy 4.0.6  <-- version here

## Version 4.0.6            <-- and here

## Last Updated: 2018-05-04

## APIVersion: 100022 100023

## Description: Master Writs: calculate material costs and automate crafting.

## Author: ziggr

...

as parameters to LibAddonMenu

Lua Code:

local panelData = {
    type                = "panel"
,   name                = "WritWorthy"
,   displayName         = "WritWorthy"
,   author              = "ziggr"
,   version             = "4.0.6"   <-- repeated here
,   registerForRefresh  = false
,   registerForDefaults = false
}
local panel = LAM2:RegisterAddonPanel(lam_addon_id, panelData)

You can access a number of fields via GetAddonInfo on the addon manager, but the version is not one of them.
There is already a thread on the wishlist asking for that, so you might want to add a comment there.

Aha! I'd never seen the AddOnManager before.

Thank you!

That's something that I think many of us would like. I have several files that need to contain the version number, not just the .txt file but also the .cmd that creates the zipfile for uploading, etc. This is how I get around that:

Have a file Version.lua that contains just one little table with all of this stuff in it.
Create templates for .txt and .cmd files, for example myaddon.txt.template.
At publication time, generate the .txt and .cmd files from the templates, taking the variables from Version.lua.

Same here. I just use a token in my txt and lua files and then run a build script which replaces the token with the real version before creating a zip archive. Still would be nice if we could use the version from the manifest in the addon code.

The version field is meant to hold an unsigned integer and is used to prevent a lower version of an addon from loading if there is a higher version. We can add an API to return this number, but it would not work with your "4.0.6" example.

Addon authors have been using "## Version: <string>" since launch. Maybe it is not officially supported?

How are we able to load the same addon twice, with different versions? The foldername would be the same for the addons thus the filenames would replace themselves and the game got no comparison to the addon versions anymore as there is only 1 folder containing the files.

The same for libraries which use libStub already to only load the "newest" version.

Quote:

Originally Posted by ZOS_ChipHilseberg (Post 34713)

Quote:

Originally Posted by Baertram (Post 34717)

How are we able to load the same addon twice, with different versions? The foldername would be the same for the adodns thus the filenames would replace themselves and the game got no comparison to the addon versions anymore as there is only 1 folder containing the files.

The same for libraries which use libStub already to only load the "newest" verison.

Maybe it goes off the ## Name field. However, with the changes to addon detection it would be possible to have the same addon hidden in a folder.

Quote:

Originally Posted by Dolgubon (Post 34719)

Maybe it goes off the ## Name field. However, with the changes to addon detection it would be possible to have the same addon hidden in a folder.

It was always possible to have a manifest in a nested folder, but the game wouldn't load the files.

e.g. this configuration:

Code:

addons/LibAddonMenu/manifest.txt

addons/SomeAddonWithALetterAfterL/LibAddonMenu/manifest.txt

One would expect that LibAddonMenu is loaded from addons/LibAddonMenu, but the game searches all nested folders and then picks the last manifest it found (it's actually a bit more complicated since dependencies also play a role). Because of that it would decide to load the nested manifest in SomeAddonWithALetterAfterL and in the past the standalone version of LAM wouldn't get loaded at all since the paths in the manifest would get treated as relative to the addon root folder.
Now with the changes applied to addon loading, the paths in the manifest are treated relative to the manifest file, which allows us to load nested addons correctly. The AddOnVersion directive comes into play when the game sees more than one version of the same addon. When no version is supplied, it will just pick the last file as explained before, but when we add a version it will always prefer the one with the highest number.

Quote:

Originally Posted by sirinsidiator (Post 34715)

Addon authors have been using "## Version: <string>" since launch. Maybe it is not officially supported?

i would love to see #APIVersion too!