Environmental Protection Addon : Discontinued & Outdated : Elder Scrolls Online AddOns

(2 Kb)

Download

Updated: 04/27/14 11:24 PM

Add Favorite

Install Help

Compatibility:	Live (1.0)
Updated:	04/27/14 11:24 PM
Created:	04/27/14 11:24 PM
Monthly downloads:	15
Total downloads:	1,468
Favorites:	2
MD5:

Environmental Protection Addon

Version: 1.0.0

by: LilBudyWizer [More]

A very simple addon for checking for pollution of the global namespace. Just disable all other addons and add:

Code:

## DependsOn: EPA

to the manifest. That's to make sure it loads before your addon. At first player activation is creates a table, EPA, that lists all the variables that weren't there at file load by data type. That is the saved variables for the addon. The addon has a known list for variables created by the client between loading addon files and activating the player. You can simply cut and paste the saved variables into the known list if you want to test with other addons and don't want to see the variables they create.

It's very easy to unintentionally create a global. All you have to do is misspell a name. You don't have to declare a variable to use it and if you don't it's global. It's easy enough to do that it's the reason I created the addon, to make sure I hadn't made any such mistakes. If you're new to LUA or mod development this can help make it perfectly clear if you don't declare it as local then it's global.

USERDATA can have a lot of entries under it because that's, mostly, your windows and controls. I haven't played with GUI elements much, but, apparently, every control creates a global name. Anything you intend to be global, or can't prevent it from being global, should be prefixed with the name of your addon.

The idea is not that you run with this all the time and you certainly should not release your addon with the dependency still in the manifest. This is intended as a final check before going live. It is for your protection to prefix your globals with your addon name. Others are unlikely to stomp on your variables when you do that. When you use common names there's a good chance someone else will as well and your addon can start crashing due to someone else completely unrelated addon.

Optional Files (0)

Comment Options

07/27/14, 08:10 PM
Minceraft Forum posts: 51 File comments: 36 Uploads: 4	HELP!!! First, Thanks again to Garkin and everyone else for the help! I was wondering what could possibly be keeping in-game location Coords from returning when I use /myloc with Skyshards or any of them from registering at the bottom of the map with MapCoordinates....I only get the basic info (zone, world, etc...)no y or z Garkin has helped alot in finding that it's not seeming to be any of my current add-ons...he tested all the newer versions together and couldn't recreate the error....maybe something like ZrMM (<<--Just an e.g., but I have used it..) could have a bad line or something that might have changed the in-game processes? This seemed to be a good spot to post this question, considering the topic and I'm still new to lua...again, HELP!!!

04/28/14, 05:14 PM
SpecialK Forum posts: 6 File comments: 2 Uploads: 0	Nice work. I try to keep my own work solid, but feeling doubious about other people's perhaps well meaning but potentially bad, maybe poorly written AddOns. Maybe your Addon can be used to catch problem ones. For me I just make everything local by default and just let the game's error handling (an extension of Lua's error and panic handlers) tell me when there is a problem (when it can't find a reference). I see a lot of people use the common Lua OOP'like pattern making their Addon modular by putting it in a table as such: Lua Code: MyAddOn = {} function MyAddOn.OnLoad() end And they probably don't realize that even this can actually be local as simple as "local MyAddOn = {}", etc. Plus there is a performance advantage as well because Lua will access locals by index vs a key/hash label (see the debug library for more on this). I miss the package/module setup too. They unfortunately nil those libs out on load. Along with "require()" too probably just to block the external DLL loading facility. It's too bad they don't just hack those things out of it (that allow external access) and leave in the rest. Note the particular flavor of Lua they are using is Havok Script. It has some neat things like it's built in performance "struct" data structure libs, etc., that ESO doesn't use, also nil'ed out. Maybe they wanted the unparalleled integrated Lua development environment (with Visual Studio plugin(s), etc). Havok Script is hyped at "2x faster..", but clearly LuaJit would leave it in the dust! Now If you look at the game's internal Lua files (google for an unpacker for "data000.dat") you see they generally use a pretty basic (not big on OOP stuff) Lua model for their internal development. Although they have a ton of built in client binds (with class like setups with metatables, etc.) too. There are some Lua module/require replacements FYI, but I'm too lazy/busy at the moment to track the URLs down. I found this good read here on the subject (from that other, unmentionable evil empire, game): http://www.wowwiki.com/Lua_variable_scoping Note a good trick to limit the scope (but things still need to be declared "local"), also to setup a garbage clean for a bunch of init stuff, and maybe help if you ever hit the limit of file scope locals, etc., is to use "do end blocks". Example: Lua Code: do ... a bunch of stuff, declare lots of locals, etc. end A read on it: http://www.ludicroussoftware.com/blo...sposable-code/ EDIT: Opps yea you can't make table functions local like that. I removed that part. Also I found making your AddOn (see my "MyAddOn" example above) local can cause a problem in some cases. Last edited by SpecialK : 04/30/14 at 12:17 AM.

04/28/14, 01:12 PM
LilBudyWizer Forum posts: 32 File comments: 11 Uploads: 4	Yeah, for this simple task seeing it when you create it while editing the script would be preferable. I just started using sublime text due to ESOlua. A package for it would be a preferable solution. Since locals are only file scope it should be pretty straight forward. I don't think it precludes this addon though. No doubt some are using Notepad to write their scripts. This partially sprung out of a discussion of standards for addons. Globals was one topic that popped up. I think the best way to encourage adoption of standards is provide tools that work better if you follow them. Right now I just needed a way to check an addon I'm working on so this is quick and dirty. I'm thinking developer tools is the path I prefer though. So I'm thinking once I get the addon I'm working on out I'll work on this. I'm thinking turn it into a debugger, i.e. inspect/watch variables. That's the best way to encourage a few standards. Follow a few standards and you get additional insight into what happening.

04/28/14, 10:38 AM
SinusPi Forum posts: 18 File comments: 5 Uploads: 3	LUAC can help, too! Running luac with the option to dump bytecode helps a lot, too, to check creation of globals directly in Lua files. luac52.exe -l MyLeakyGlobalsFile.lua ... 624 [4104] SETTABUP 0 -234 120 ; _ENV "BlaBlaLeak" ... Any line with SETTABUP ... _ENV "..." essentially sets a global. Find those and you're gold.

Report this File