[outdated] Do not change flag of Disable outdated addons when APIVersion raise
 

A lot of users blame a certain part of code which trigger an obvious thing which disable their addons. #unacceptable

Because disabling all users addons due to some tiny part of retarded users which don't update them the second after they're published is way non-friendly, I kindly ask you to change the behavior of AddonManager to do not change the "Disable outdated addons" flag when API bump.

Thank you

PS: A bit of humour is hidden in that request, but this one is serious.

I support this request

It's easily changed. I'd like some more opinions on this though.

I think in its current form the checkbox is useless. Either a users doesn't know about it and complains that his addons are disabled after a major update, or he does know about it, checks it without thinking what it actually means and then proceeds to complain that some addons throw errors without even attempting to update them. :rolleyes:
Of course that doesn't apply to all users, but overall I think it is more of a hassle than helpful.

Right now, ticking the box to enable outdated addons feels a lot like ticking the "I agree" box in the TOS. It's a standard thing that people do without really thinking when a new major update is released.

That having been said, even though I personally treat it in the same way as click-away boilerplate, I think it's still a nice thing to have, because it's a reminder to the users that they should probably be on the lookout for addon updates. Yes, it's unfriendly, yes, it's an annoying thing that people have to remember to check, but sometimes a little nuisance is useful, particularly since it happens only once every few months.

A somewhat better system would be to make the enable-even-if-outdated option be addon-specific, to encourage the user to reevaluate their suite of addons and make a decision on a case-by-case basis. And this option could be made to persist across major updates, so that "outdated" stable addons (e.g., Dressing Room) that have a reputation of never breaking across updates can be whitelisted by the user.

Maybe instead of the checkbox, an exclamation mark at each addon with a tooltip "This addon was not tested with the current version. You may experience problems. Please consider to update." Or so :o
Do not use the term "out-dated". This sounds as if you know it will not work already.

/edit: Which is the same direction as code65536 said. I was too slow :)

Oh yes. I keep seeing threads on reddit where people ask why ESO says an addon is outdated even though they have the most recent version of the addon installed.
Using "This addon was not tested with the current version of ESO. You may experience problems." instead of "outdated" would certainly help in those cases.

I agree, once that setting is on to allow add-ons regardless of what version is in their manifest, it should stay on. I also agree that listing add-ons as "Out of Date" is not the best way to do things either. Most add-ons aren't affected by a single version increase of the API and continue to run fine. Building on the exclamation mark idea, perhaps what's listed in the manifest should be used to mark the latest version of the API that the add-on has been tested to be compatible with.

And if you discuss about changing the addons page: There are two "nice-to-have" features:

1. Please make ## version: an offical manifest tag.
   A pure informational string available via GetAddonInfo/AddonManager. Maybe length limited to what a serious version number looks like. (24chars ?)
2. Create a function to open the file location in the explorer (I don't know how MAC calls it) where you are looking for addons.
   Some users have difficulties to find the right folder. Or get redirected to OneDrive.
   It could be a pre-game-only or private function. Although I don't know why it should be.

oh and btw, is there a way to call # APIVersion (in manifest) from .lua file?

I really support this request! The curent checkbox is just something like a pain-in-the-*** box that some users don't know what it is about, and others just simply enable to get non-working addons "all of sudden" working again.

The whole API version check in the addon manager is soemthing that can work, but most of the time got no connection to the real addon's functionality or state of changes.
I'd rather like to mark my addons as "compatible" with a certain API version by changing the API in the manifest file, but do not let users check a checkbox to enable the addon. Just enable them!

And show some info next to each addon line, if the GetAPIVersion() function returns a number > than the one in the addon manifest file (like sirinsidiator proposed already). But don't tell the users "The addon is not working anymore" but somethign like "Check the addon's description/changelog to see if the addon is compatible with the current API version. If you encounter any error please consider to update the addon, if available!".

In the end I don't want to edit and update api manifest txt files just because users don't remember to check a simple checkbox, or refuse to do so because they think the checkbox will break their game (no jokes, this was an answer I once got!). I don't have the time nor will to support this any longer :-(

After yesterday's discussion on gitter, I had the following idea. In the addon menu instead of calling an addon outdated, call it "untested" and show how many updates are between the current api version and the one the addon was tested with (e.g. "untested for 3 updates"). When the specified version in the manifest is higher than the current game version you'd just show "untested".

When the user logs in after an update, he sees a dialog on the character selection screen "Disable untested addons?" with some explanation why and what could happen and that he should check if there are new updates for the addons. The dialog then has two buttons "yes" and "no" and a checkbox "remember my choice" which will be a new setting in the interface settings menu "disable untested addons on api updates (yes/no/ask)".

The checkbox in the addon menu can just stay there and everybody will be happy. :D

EDIT: or maybe don't add it to the setting and make it a hidden flag in the UserSettings.txt which addon authors can then adjust and regular users will always get the dialog

The author being able to choose would be nice. Normally, CS catches fire on a new API update, so I'd like to disable it (until I upload the new one), but this patch for example, it would've still worked.

Would we assume if the setting is left off that it should be disabled or enabled? The addons that likely suffer from this the most are discontinued where the author won't be changing the flag.

Hm. That would be a separate feature altogether and a reverse of the APIVersion directive. A "MaxAPIVersion" so to speak which forces the addon to disable once an update comes around. Sounds nice and useful when you know that the next patch will break the addon. :)

I'd like to keep it simple and less work intensive for the addon devs please.

Updating an addon's txt file, and thus the total ZIP archive, on every patch just to please some "lazy guys" and a system which compares numbers (ESO client) is imo useless.

Just inform the users after a patch that addons need to be checked (ESO ingame message, once).
If the refuse to do so, it's their problem and fault.

If a lua error message appears check the callstack internally and if NO addon was involved tell the user within the message to contact the support or write a /bug message. Maybe put an "copy error messgae to /bug report" button in it.

If an addon was involved tell the users to check their addons and maybe color the line with the addon name in red so they directly see it in the error message.

Whatever it takes to change this please do not force us to count + 1 in a txt file after each patch just to please a comparison of numbers :rolleyes:

The recent shop issue is a good example of needing some method of knowing when an addon is at fault. I'm assuming it was caused by addons prehooking keybind bars or something (too lazy to look into it) and messing up the whole thing. It'd be nice if it knew when an addon messed it up (even if it only lists one addon). You turn that one off and then the next addon causing it would be shown.

I support this as well. For the most part I think if a user makes a conscious decision to let outdated addons run at some point - API bumps shouldn't reset that setting.

It would be really nice to know if an add-on faulty, makes me crash or time out. But any report I can send not showing any add-on. Really hard to track it back.