Minion Addon Detection Assistance

[Shirik]

The next patch, 2.2.2, of the WoWI module will implement an override mechanism for the addon heuristics, for authors that wish to support it. This feature is being added due to popular demand.

I want to make it perfectly clear that this is not required by anyone, and even those addons that will adopt this method I still want to fix in the heuristics as well.

If authors wish to supply minion's wowinterface module with additional data, they can add the following information to the TOC file:

## X-WoWI-ID: 1234

Where 1234 is the ID of the addon. This will ONLY apply to the WoWInterface module. Other modules may have their own mechanism for handling this.

For assistance with addons having multiple folders, the following system can be used:

## X-Child-Of: FolderName

Where FolderName is the name of the folder whom "owns" the addon. Please note this option is case sensitive and will not match differently cased names.


Again this is not required, and I do not want this taken as an indication that I will be "giving up" on improving the heuristics from this point on. I still have several other changes to make.

Thanks,
-- Shirik

[orionshock]

Just for clarification. While this may be obvious, just wana ask

the [[ ## X-Child-Of: FolderName ]] should only be used by modules packaged with in the same project right? "Child" addons that are not part of the parent project should not use this but simply act like an independent addon?

IE : Dominos has several modules that comes with it in the same package. Those ones should be using the tag, where as the addon "FuBar_DominosFU" should not use this tag as it is really another project.

[Shirik]

That's correct. Essentially, any addon with this field will be exempt from updates. The "value" portion of it only serves to confirm to Minion the reason for its exemption.

[Odlaw]

What ever happened to the X-RelSite-WoWI field? I seem to recall that being used for something.

[haste]

Originally Posted by Odlaw What ever happened to the X-RelSite-WoWI field? I seem to recall that being used for something.

It was used to auto-generate the external links over at the old WoWAce wiki. You can still find the info here.

[Tristanian]

These tags are pretty handy tbh, since they provide an easy and secure way to separate child addons (modules, config panels, LDB feeds etc). Think I'm gonna start using them right off the bat.

[Maul]

I will start adding these tags right away to my addons.

[Slakah]

I know people will possibly disagree with this, but imo it would be nice if WoWI had an option on upload to add this automatically to the toc.

[Cairenn]

I will need to talk to the rest of the staff about this but it goes against everything we've always said, that being that we will never touch an author's files.

[orionshock]

Originally Posted by Cairenn I will need to talk to the rest of the staff about this but it goes against everything we've always said, that being that we will never touch an author's files.

Aggreed, automagic that is not understood can be a bit uneasy with some people. However, if you make it an option via An additional check box "[ ] Add Updater Meta Data to ToC? " That could work. Considering that the use of the tags in Minion is totally not-required.

I will say that having options is nice

[Shirik]

Originally Posted by Slakah I know people will possibly disagree with this, but imo it would be nice if WoWI had an option on upload to add this automatically to the toc.

The #1 reason I made this optional is because of this fact - this should NOT be done. Doing this would wreak havoc on other updaters whom rely on files being consistent (such as the Curse client). If something like this is added to a file, it should be the same across ALL distributions of the file, whether or not they're on WoWI. This way, this problem doesn't occur.

[algritz]

Updated Scout to use the tag.

Thanks !

[orionshock]

Originally Posted by Shirik Doing this would wreak havoc on other updaters whom rely on files being consistent (such as the Curse client). If something like this is added to a file, it should be the same across ALL distributions of the file

Shirik has a point...

IIRC WoWI has a packager for their SVN Repos? if it does then it could go the way of curseforge's packager and automatically add it in.. tho.. there might be some strife about that

[dropper]

What method does the Curse Client use? Is there something that prevents Minion from doing the same?

Keith

[orionshock]

Originally Posted by dropper What method does the Curse Client use? Is there something that prevents Minion from doing the same?

Not sure about when you manually upload files, but the curseforge packager that makes the zip from the various reop's automaticall adds some x-curse data to the toc file. However, them doing this is well known and uderstood. Whereas WoWI has (IIRC) always been about choice and dosn't do anything overly automatic for authors; Opt-In has always been their style.

[Shirik]

They also hash the files and compare the hashes against what is on the server, from my understanding. This is why I WILL NOT force something onto files, nor will I add files to your installation directory, because it will break that updater in the process.

(Similarly, I defend against this process to ensure CC does not cause the same havoc in return, and thus cannot use this hashing algorithm as a method of determining which addon it is on the server -- in my opinion it's too unreliable anyway).

[DonCorneo]

The Curse Client is reporting that a few of the addons updated by Minion do not match the Curse Client data base. It was also happening with the old WoWI Client.
The feature as far as I can tell was incorporated to detect addons updated by WoWMatrix Client and other "leeching" clients. It is as unreliable as Shirik thinks it is since it is also picking up legitimate addon client updaters (well, at least WoWI's clients).

I think the method Shirik is looking to use for the short-term fix will greatly help reduce the wrong addon detection problem.

It would probably help if all authors used the same standard format:

## Interface: WoW version the addon is made for
## Title: The name of addon
## Version: For major changes to addon (Not the version of WoW Interface)
## Sub-Version: For minor changes to addon, such as bug fixes
## Author: Name of person who originally wrote the addon
## Maintained-by: Name of person currently keeping the addon updated
## X-Date: The current date addon is released on
## Notes: What the addon does, or other info

and then other information.
This would help all client updater programmers to be able to have the client better identify the addon, and if it needs updating.

A good number of Authors use a similar format, but certainly not all. Some .toc files are a huge mess and I'm not surprised there are problems with the clients figuring out if it is old, new or even the right addon. I'm suggesting the above format to give the programmers more information for the client to verfiy the correct addon and version.

[dropper]

Didn't want to double post, so please look at some of my findings (msg 9-10) in the carbonite thread.

Keith

[ComputerNerd]

How about an external file being added, one that would just sit in the zip but be extracted to the \Addons folder.
So the zip would be something like the following
\addon_source.dat
\addon_folder\
\addon_folder\file 1
\addon_folder\file 2
etc
This then would allow such data to be added - obviously with the name of each folder the addon consists of, but wouldn't impact on curse updater or any other since the addon files themselves aren't being modified - only an extra file added to the zip, which then exists outside of the addon itself.

[Slakah]

I'm pretty sure the Curse Client doesn't like any discrepencies in the folder contents, so adding one .dat file for WoWI downloads would still cause the Curse Client to throw a fit, and I really don't understand why the Curse Client does this, it just seems like strange behaviour.