Thread: Addon Etiquette
View Single Post
04/23/14, 08:57 PM   #39
Vuelhering
AddOn Author - Click to view addons
Join Date: Mar 2014
Posts: 169
Mostly just answering the OP. I'm late to this discussion I guess.


Re dependencies: Minion doesn't check dependencies. It probably should, but that does add a level of complexity. Individual addons can have dependencies.

Since you mentioned not including optional dependencies, many addons are dependent on LibAddonMenu and embed it in the download (which you suggested addons should not do). If you want a consistent look & feel, unlike Apple with Inside Mac, ZOS has not released a set of books (or even published their interfaces) or a set of libraries to help with look and feel. Even so, look & feel is ultimately up to the programming author. If ZOS wants a consistent look and feel, they can make a good set of libraries for it and a very clear, documented API that's not "discovered by the community and entered into a wiki" and doesn't require going to hacking and reverse-engineering sites to pull their Lua code out for examination just to write a program to support their product.

Re saved variables: Generally, no addons should intentionally touch another addon's saved variables. Any updates of the original can break everything. If an addon is designed solely to massage another addon's saved variables, absent some seriously transformative results, it's probably a derivative work of the original addon author. This includes things like bugfixes.

Re formatting: An addon is for end users, not for addon programmers. If you format like ****, you are the only one who suffers as the author. If it's buggy and can't be fixed easily by others, you also suffer as the author because nobody will fix it for you. If we trust the addon API, then we should never need worry about what is in the addon code.

I'm a big fan of releasing code and allowing others to maintain. But that doesn't mean I'll be held to someone else's standard of coding.

Frankly, I think all addons should be compiled or obfuscated by default, which will prevent issues that arose in WOW where people were stealing and distributing the addons then adding beg screens for money that didn't go to the original author, and it would also help prevent issues with copyright bickering when someone "borrows" 10 lines of code or something. I will also note, the day ZOS goes the way of blizzard and forbids obfuscated code is the day I will stop distributing addons (just like I did with blizzard with the Ni Karma System, a highly-acclaimed loot distribution system way back when). Bliz basically made a claim that "Your lua code runs on our interpreter which we got from Lua.org, therefore it's an extension of our game, therefore we can make a land-grab and try to steal your copyright and tell you what you can program in our stolen language, Lua." Tons of addon authors quit the game and stopped distributing addons. (Literally, tons. Including me, and I'm skinny. :-)

Re globals: Global variables should basically not be used, because they can have serious unintended side-effects by stepping on other things. I consider globals to be a memory leak. If they are necessary, they should be hidden within a single table clearly tied to your addon (and probably sharing the same name). If I wrote the Vuel Superwarlock addon, the only variable I should use is Superwarlock, where I can embed Superwarlock.config, Superwarlock.counter, etc.

Last edited by Vuelhering : 04/24/14 at 02:04 AM. Reason: clarified look & feel section
  Reply With Quote