WoWInterface

WoWInterface (https://www.wowinterface.com/forums/index.php)
-   AddOn Help/Support (https://www.wowinterface.com/forums/forumdisplay.php?f=3)
-   -   Sanity Check Optimization (https://www.wowinterface.com/forums/showthread.php?t=52805)

sirann 10-07-15 09:53 AM

Sanity Check Optimization
 
Hello all,

I found I was frequently forgetting to do basic things like re-equip trinkets/cloaks/rings when I use the various portal items that use these slots. Further, I found myself forgetting to reapply poisons when swapping between specs. Lastly, I would hate going across my logs for a night to find that I had run out of agi pots and was not pre-potting/double potting.

This addon essentially performs 3 checks every time a readycheck is performed, first it makes sure my ilevel is reasonable, then it checks to ensure I have a DPS poison on, and lastly it scans my bags to check the number of pots I have (if any).

If the conditions aren't met, it just puts a nice annoying box of various colors over my character reminding me that I am a failure in life.

The code can be found here: http://pastebin.com/pMhDWT3v

The code works exactly as I want, and while not super duper resource heavy, I wanted to throw this out to the far better coders that visit this site to see if I could optimize it further!

Phanx 10-07-15 10:58 AM

There's no need for separate frames for display and handling events. Being hidden or shown doesn't affect whether a frame receives events.

Declaring all your variables at the file scope instead of the scope where they're actually used isn't a good practice. Your "total" and "equipped" variables are only used in the PLAYER_AVG_ITEM_LEVEL_UPDATE event handler, so you should just stick a "local" in front of the line that assigns them the values returned by GetAverageItemLevel().

Similarly, when you need to run a function to find a value (eg. your CheckBags function) rather than declaring a variable at the top of the file, running the function to update the variable's value, then reading the variable, it's cleaner to just have the function return the desired value. That way you just assign it like any other function regurn, eg. "local count = CheckBags()" -- but in this case, you don't need that CheckBags function at all. Since all you want to know is "how many of item 109217 do I have in my bags?" you can just use the API function that answers that question:

Code:

local count = GetItemCount(109217)
You could also, in theory, display the three boxes side by side, so in case you're failing twice (or thrice!) as much you can see. :p

sirann 10-07-15 03:19 PM

Quote:

Originally Posted by Phanx (Post 311382)
Code:

local count = GetItemCount(109217)

And here I was thinking I had come up with an elaborate solution to having multiple stacks that, individually, are less than 4, but together would be more than 4.

Quote:

Originally Posted by Phanx (Post 311382)
Declaring all your variables at the file scope instead of the scope where they're actually used isn't a good practice. Your "total" and "equipped" variables are only used in the PLAYER_AVG_ITEM_LEVEL_UPDATE event handler, so you should just stick a "local" in front of the line that assigns them the values returned by GetAverageItemLevel().

I was under the impression that every time, in this case, a ready check went out, or my ilevel changed this would write "new" variables with total and equipped for instance as names. I put them outside of the scope so the variables are only set aside once, so the only change that occurs is the values associated with them, thereby reducing memory usage. Doese LUA just overwrite the variables in the same memory space, thereby not changing memory usage at all? Does overwriting use CPU, moreso than changing the value the variable is equal to? My impression is obviously incorrect, but, could you point me in the right direction of how lua handles variables in the memory/processor? Essentially all of my code lists locals just above (but always outside) functions or event handlers.

Torhal 10-07-15 10:21 PM

Variables are nothing more than names you use to refer to values. You're not allocating extra memory when declaring them, or even when switching them to hold a completely different value. There is a temporary and negligible allocation under the hood, of course, just as a pointer in C, C++, or equivalent languages has, but it's done on the stack and is thus freed when the variable leaves scope.

You shouldn't be stingy about using variables, since their entire existence is designed to facilitate the flow of logic and readability of your code.

Yukyuk 10-08-15 11:06 AM

Someething every day.
 
Quote:

Originally Posted by Torhal (Post 311390)
Variables are nothing more than names you use to refer to values. You're not allocating extra memory when declaring them, or even when switching them to hold a completely different value. There is a temporary and negligible allocation under the hood, of course, just as a pointer in C, C++, or equivalent languages has, but it's done on the stack and is thus freed when the variable leaves scope.

You shouldn't be stingy about using variables, since their entire existence is designed to facilitate the flow of logic and readability of your code.

And so we learn something new every day.
Thanks to the both of you (Torhal and Phanx).


All times are GMT -6. The time now is 08:11 AM.

vBulletin © 2024, Jelsoft Enterprises Ltd
© 2004 - 2022 MMOUI