Please support multiple clients in .toc ## Interface

Gello-89115 · April 4, 2021, 2:10am

I’ve written a handful of addons that work in both Retail and Classic that will support TBC Classic. Right now I use the retail Interface number and tell Classic users to load out of date addons.

It would be nice if the .toc supported multiple Interface numbers so one upload is properly “up to date” for the clients it’s written for.

Barbearian-heartseeker · April 4, 2021, 2:19am

I don’t understand what you just said, but I am onboard.

Luckey-mankrik · April 4, 2021, 2:36am

Could you not make two versions of the addon, Classic and Retail?

This is what I am seeing most addon developers doing now.

Even if the only difference is the .toc file on each version.

Gello-89115 · April 4, 2021, 3:05am

That’s a solution now. But with TBC we’d need to create three versions: Retail, Classic and TBC. I upload to both wowinterface and curse, so this is uploading six files for one addon to keep it up to date.

For the previous poster, you may have noticed in the addon screen that if you uncheck ‘Load out of date AddOns’ in the topright, some addons are disabled due to being out of date.

Every addon has a .toc file that includes the line like:

# Interface: 00000

where the number says what version of WoW it supports

Retail: 90005 (9.0.5 patch)
Classic: 11306 (1.13.6 patch)
TBC Classic: 20501 (2.5.1 patch)

When a major patch happens (such as when retail goes to 9.1), addons that don’t update to the new number (likely 90100) are now out of date and will not load unless ‘Load out of date AddOns’ is checked.

So users who prefer a stable experience can keep ‘Load out of date AddOns’ unchecked and on patch days any addons that haven’t been updated will not load.

All well and good, except some of us have addons that work in multiple clients. I have Select, Grounded, TinyPad and QuestBindings at least. All four of these are tailored to work in retail and classic. (Adapt and others naturally work without extra work–aside from the toc number.)

Their interface number is 90005 for all four, so they’re up to date for retail but technically out of date for classic; despite the work I put in to make them work in classic. We can’t make an addon up to date with both unless we post two separate versions of the addon. With TBC classic coming online, we now have to post three separate versions of the addon, or we have to tell classic and TBC classic users to load out of date addons.

A nice solution would be to allow multiple interface numbers. If the client is at least one of the posted numbers, then the addon is up to date.

## Interface: 90005, 11306, 20501

or

## Interface: 90005
## Interface: 11306
## Interface: 20501

or if they don’t want people “post-dating” their addons, specify the client:

## Interface-Retail: 90005
## Interface-Classic: 11306
## Interface-TBC: 20501

This change of course would have to happen on all three clients, but they can do it for 9.1, the next classic patch and of course TBC when it releases.

Luckey-mankrik · April 4, 2021, 3:07am

Can Curse and wowinterface support push/pull from Github? You could create a small script to update the .toc files, push them to Github and have a push or pull to curse and wowinterface (if they support that).

Luckey-mankrik · April 4, 2021, 3:12am

To be clear, I do agree with you, the client does need to support multiple client versions.

It just never was a problem till classic, but with TBC, it is most likely time.

Gello-89115 · April 4, 2021, 3:17am

Yeah it’s probably time I sat down and figured out a scripted update scheme. But I’ve been doing it this way for 50 different addons or so over the years, it’s hard to change!

Khasar-903854 · April 4, 2021, 9:21am

Two questions if you don’t mind. Is an addon scripted xor compiled? Can an addon access the wow version number?

Gello-89115 · April 4, 2021, 10:01am

Scripted in the sense they’re text files. Lua gets compiled into bytecode as it loads.

An addon can easily get the current build:

/dump GetBuildInfo()

It’s the fourth number.

Blizzard removed the file i/o from their implementation of Lua. Addons can tag variables to save themselves on logout and load them back on login (savedvars), but that’s the extent that addons can interact with files.

Khasar-903854 · April 4, 2021, 10:41am

I was just wondering about the feasibility of combining the code for a given addon into one file and using a conditional to move to the part that pertains to a given version (classic, tbc classic, SL, etc., so that you’d only have one file to deal with.

Gello-89115 · April 4, 2021, 2:46pm

That’s basically how we make one file support different versions, though with WOW_PROJECT_ID commonly rather than GetBuildInfo(). This isn’t really the problem but thanks for the suggestion.

The problem is we can’t make an addon ‘up to date’ (having the correct ##Interface number in the toc) with multiple versions of WoW. There is no lua/logic in the toc. We are allowed one number. So we can only be up to date with one version of WoW.

Gello-89115 · May 4, 2021, 1:58am

It looks like this is solved in the Burning Crusade beta client.

github.com/Stanzilla/WoWUIBugs

Multiple Interface Version Support

opened 07:51PM - 24 Mar 21 UTC

closed 08:06PM - 30 Apr 21 UTC

Meorawr

Feature Request

**This request has been implemented [as described in the linked comment](https:/…/github.com/Stanzilla/WoWUIBugs/issues/68#issuecomment-830351390).** --- We'd like to request a way to specify multiple versions in a TOC file that will permit addons to no longer be flagged as out-of-date unless zipped up and distributed as separate packages for each client. For the past couple of years of Classic's existence the approach used by addons which support both game clients has generally been to ship two _possibly otherwise identical_ copies of their addon with the TOC interface version corrected for each client. Depending on how the upcoming TBC client is released, we could be looking at doing this a third time if the client for it were separate from the existing Classic one. --- The proposal is to have the client support different Interface version fields per client flavour, allowing addons to fill these in as needed and only provide a single TOC file that'll work on all of them. As an example of what we'd like to do: ```toc ## Interface-Retail: 90100 ## Interface-BC: 20501 ## Interface-Classic: 11307 ## Title: My Awesome AddOn ``` If the above TOC file were loaded into a client which supported per-flavour versioning, what we'd like to see is that this addon not be flagged as out of date on either the Retail or Classic/TBC clients so long as the interface versions given match their respective client. Note that the particular names associated with each client ("Retail", "BC", and "Classic") are for exposition only and can be changed as needed, however community support appears to favour these three names. One additional extension that we'd like is the ability to also flag addons as **completely incompatible** with a client flavour, such that they'll show as "Incompatible" in the addon list and the client will refuse to load them entirely. As the feature and API difference between Classic and Retail has grown, a number of addons have either [had to add code to explicitly detect being loaded on the wrong client](https://github.com/WeakAuras/WeakAuras2/blob/b0433763d04d3748420ed5e03c1402ac8d868511/WeakAuras/Init.lua#L45-L53), or simply aren't compatible to begin with. ```toc ## Interface-Retail: Incompatible ## Interface-BC: 20501 ## Interface-Classic: 11307 ``` The expectation is that if the above were loaded into the Classic/TBC client then the addon would be loadable, whereas if it were loaded into the Retail client then it would be marked as "Incompatible" in the addon list and the client wouldn't permit it to be loaded. For compatibility with existing addons and processes, the existing "Interface" tag should remain as-is, such that its usage specifies the supported interface version for the current client regardless of flavour. In the case where an author uses both a flavour-specific and the general "Interface" tag the behaviour should probably be that the most-specific tag is used: ```toc ## Interface: 20501 ## Interface-Retail: Incompatible ``` With the above the expectation is that the addon would be marked as "Incompatible" on Retail clients, and flagged as supporting interface version 20501 on everything else. --- One final idea that's been suggested a few times is to permit specifying multiple interface versions as a comma-delimited list primarily to assist with flagging addons as compatible with a currently-released and in-test patch. **Note that while this would be nice to have, it shouldn't be considered as high priority as the rest of the proposal**, and can be omitted if the risk of addons abusing this is considered undesirable. ```toc ## Interface-Retail: 90005, 90100 ## Interface-BC: 20500, 20501 ## Interface-Classic: 11306, 11307 ``` If support for comma-delimited versions were added, the expectation is the above would be marked as not being out-of-date for any of the listed interface versions.

In a future Classic and BCC build the client will support loading distinct TOC files on a per-client basis. The implementation we’ve been informed about is as follows:

If an addon is loaded on the BCC client, the client will first look for a TOC file whose name is suffixed by “-BCC” (eg. “MyAddOn-BCC.toc”) and load that if present. If not, the client will fall back and load “MyAddOn.toc”.

If an addon is loaded on the Classic client, the client will first look for a TOC file whose name is suffixed by “-Classic” (eg. “MyAddOn-Classic.toc”) and load that if present. If not, the client will fall back and load “MyAddOn.toc”.

If an addon is loaded on the Retail client, the client will first look for a TOC file whose name is suffixed by “-Mainline” (eg. “MyAddOn-Mainline.toc”) and load that if present. If not, the client will fall back and load “MyAddOn.toc”.

I just made a Select-BCC.toc with ## Interface: 20501, and left Select.toc as ## Interface: 90005. The addon is up to date on both TBC and retail from the exact same files (junction link).

I’m very happy with this. Thank you Blizzard!

system · July 3, 2021, 1:58am

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.