Energized
Inspired by the now discontinued add-on BuffEnough, Energized answers the simple question: "Am I buffed?" Energized functions as a LibDataBroker (LDB) feed whose icon changes depending on your disposition. The tooltip lists which buffs you're missing, along with who is likely to be responsible for the buff. Energized is optimized for max-level players, and primarily focuses on PvE (but also supports PvP content).
Features
- Smart buff grouping. Energized uses a very flexible grouping system that lets it handle all equivalent buffs and consumables in the game, with room to grow as more become consolidated.
- Low resource usage. Energized has been written for efficiency. It uses very little CPU time (particularly during combat) and very little memory. The configuration UI can be loaded separately for even more savings.
- Highly configurable. Every single buff and consumable rule in Energized is exposed to the user through an advanced configuration system. This gives you a visual display of exactly what is being checked, and lets you configure absolutely everything.
- Advanced tooltip. Energized uses a two-level tooltip, letting you mouse over any missing buffs to see all the people who could be providing them, and which buffs or consumables make up that buff group.
- Understands your needs. Out of the box, Energized contains smart defaults for your class (and in many cases, your spec). Like to change specs a lot? Energized knows when it happens and automatically adjusts.
- Quick disable. Don't care about a buff at the moment? Click it on the tooltip to disable it for this session. Joining a new group, reloading your UI, or logging out will enable it again.
You should also install
- Energized works best with an LDB display like Fortress, Button Bin, or Titan Panel. If you don't have a display, turn on Energized's minimap icon. There are lots of displays available — if you don't like one, try another!
- AddonLoader is highly recommended. This will let you keep the configuration UI unloaded until you need it.
Comments, bug reports, discussion
Help translate Energized
Click here to help translate Energized into your language.
Frequently asked questions
Does Energized require any configuration to work?
Nope! Energized is intended to work perfectly for the majority of players without any changes to configuration. Should you wish to dig deep, however, you can change literally anything about how Energized operates, including every buff and consumable it looks for.
Why is Energized slow to react when things change?
Energized has been written for maximum efficiency when it comes to CPU usage. It won't scan anything more frequently than once every few seconds (configurable). Certain types of actions (like changing your pet's attack mode) won't be picked up until Energized does it's automatic scan, which occurs every 10 seconds. In general, it'll just be a moment before Energized catches up. Just be patient — your framerate is better because of it!
Energized doesn't work very well for leveling. Why?
Energized is not intended to be used by leveling players.
How can I use different options for different specs?
In your Interface Options menu, click the + next to Energized, then select Profiles. Use this screen to create two profiles — one for each spec. Put yourself in the profile you want for your current spec. Then turn on Enable dual profile and select a profile to switch to when you change to your other spec.
There's still a gold border around the minimap button i'm afraid :/ It shows when the red X is showing aswell. I'm guessing something in r82 is the cause of this?
I noticed the minimap button has a golden circle around it when the addon is disabled (or is hidden, when there's nothing to report).
Pic: Your text to link here...
Is this a bug in your addon, or is it related to the minimap somehow?
I have no interest in internet-troll-debating about something who's apparent sole purpose in existing is not to rationally discuss whether "its worth it to invest code time in this issue" or something else relevant. But rather to just flat out deny an issue exists. Something that may be fun for the denier, but has little use. Better uses for my time than that. So final words on this below.
I haven't seen the v2.5.x series of OmniCC pass 9-11 CPU/second when active. And as I mentioned below...its only relevant in context. The similar mod Cooldowns uses much (much) more when active. It has less to do with "one mod creating FPS lag" (which can in fact happen), but with software design principles, relative comparisons, etc..
And finally...it all adds up, no matter what the initial number is. Good luck.
I resisted that because it fragments the comments. I prefer them here on the add-on page. :)
Easiest is to just create a topic for it, under the ''Raid Addons'' section maybe :P
You can use standard BBCode to quote:
I've put a ticket up on CurseForge to add a "quote" button to these comments. Probably won't ever happen though, heh. Or maybe I missed an obvious easier way to do it.
There is equivalent markup in WikiCreole, I think it's:
<<quote>>something<</quote>>
Yup, error is fixed now. Also have no idea how to quote on here, but here's to Zidomo:
Another example is OmniCC (the latest stable version atleast, beta version behaves more nicely). This has spikes of 20 CPU, also with no visual FPS slowdown whatsoever. If you really do get FPS slowdowns at only spikes of 4.6 CPU then something else is horribly wrong.
Skylinee (in case you didn't look at the ticket): the error on line 1666 should really be fixed now. I did repro it. It's possible it's still broken in some strange situation (I just tested the login case). Let me know.
Regarding the map icon. There are exactly two lines of code in Energized that make it happen. As follows:
If you can spot the error, please help. :) I'm really not doing anything other than telling the library "hey you, please turn on the icon". I suspect this is an issue with the library.
Edit: I added an extra line of code in r82 that attempts to force the library to either show or hide the icon. It's not supposed to be necessary, nor is it necessary in my testing, but maybe that fixes the issue for you.
I'd like to give a little more background info on the CPU discussion, in case it helps.
The reason for the CPU spikes being higher than BuffEnough is simple: every single check in BuffEnough was hardcoded. Not only is that a maintenance nightmare, but it's totally inflexible. The design goal for Energized was to expose 99.9% of the checks to the user for configuration. This means we iterate over a table of checks every time we scan. We do this as quickly as possible, but it's still technically more CPU cycles per scan than BuffEnough. This is the tradeoff for flexibility.
That being said, BuffEnough scanned all the time. Constantly. No throttling. (Except in combat, where you could just turn it off, which is a bit brute force IMO.) Energized only scans every 3 seconds out of combat. So although each scan might take a little bit more CPU, we do it far less frequently. The overall result is more configurability and less CPU usage in aggregate.
At some point I would like to try altering the scanner to spread it out across multiple frames, which I think would smooth out the CPU usage and eliminate any issues. But like I mentioned, it's a pretty big rewrite. :)
Odd. But...it hasn't happen here with a full mod load either. Might have had something to do with the testing specifics. Which were:
r77 of this loading, Ace3 r965 totally disembedded, other libraries embedded, OptionHouse, AddonLoader & NinjaPanel (one of only 2 LDB full displays I have come across that doesn't also use Ace3 or other CPU-consuming libraries; great for testing purposes. The other being tekblocks. But that has problems with displaying several LDB mods whereas the other rarely has problems). And that's it; no saved variables from prior during the test either.
Testing that version again, same issue, whether reloading the UI or completely exiting & coming back. The minimap icon goes away on coming back despite it being checkmarked in options. But if it doesn't occur with Ace3 embedded, etc., its likely not a high priority to fix.
Yay...the first UI mod CPU-usage denier troll I've ever seen...lol. That's your prerogative. Its not mine.
Yah sure. So you have used QuestHelper at 100% /qh perf, RedRange or the like in a 25-man raid and you were without any FPS drops whatsoever? Again, yah sure ;).
Like crazy? Bartender4 v4.4.2-12-g94f3b58 uses about 8-9 CPU/second (independent of Ace3) with a few bars active & a full bar icon load. One of the two lowest CPU consuming bar mods out there; the other being Dominos with a similar load. Its not necessarily the "total" that's a concern, its how the mod compares with other ones that have similar functionality. As well as optimizing a mod, etc. (see below).
CT_BarMod, on the other hand, uses 50+ CPU/second continually. Debugged a couple guildies here trying to determine why they always lagged out when Marrowgar's ice trails hit. Turns out they were both running CT_BarMod. Switched one to Dominos, one to Bartender4 (different preferences), no more problems.
--One software development goal - - and that of many authors on this site - - is to create mods with a minimum of "fluff", coded to function efficiently. This is a new mod and would like to see it become as efficient as possible while doing its job :). BuffEnough - - the pre-cursor to this mod - - did it like that without CPU spiking.
An author may have different priorities. But I really appreciate the effort Allara is putting into this mod as well as the efforts to address this issue brought up. Look forward to this becoming The Best Buffing Mod Ever =D.
I got a ticket on that one already but wasn't able to reproduce it. I'll check in an attempted fix, but since I didn't reproduce it, I have no idea if it fixes it.
1x Energized-79\Core.lua:1666: Usage: UnitIsUnit("unit", "otherUnit") Energized-79\Core.lua:1666: in function `PlayerHasTalent' Energized-79\Core.lua:1189: in function `_Update' Energized-79\Core.lua:1307: in function `Update' Energized_Options-r79\Options.lua:380: in function <Energized_Options\Options.lua:378> (tail call): ?: <in C code>: ? <string>:"safecall Dispatcher[2]":9: in function <[string "safecall Dispatcher[2]"]:5> (tail call): ?: AceConfigDialog-3.0-49:797: in function <...nfig-3.0\AceConfigDialog-3.0\AceConfigDialog-3.0.lua:612> (tail call): ?: <in C code>: ? <string>:"safecall Dispatcher[3]":9: in function <[string "safecall Dispatcher[3]"]:5> (tail call): ?: AceGUI-3.0-33 (Ace3):314: in function `Fire' ...ns\Ace3\AceGUI-3.0\widgets\AceGUIWidget-CheckBox.lua:68: in function <...ns\Ace3\AceGUI-3.0\widgets\AceGUIWidget-CheckBox.lua:57>:
-I get these now and then with the latest alpha, recently when entering a vehicle.
Complaining about 4.6 CPU spikes is being way too picky, as this addon really does quite alot to make sure you're buffed at all times. I've ran addons in the past that used 40+ CPU/sec alone without any FPS drops whatsoever (on a singlecore 2ghz CPU/7800 GTX btw).I see popular addons like Bartender eating CPU like crazy, but i don't see people complain about that.
Zidomo: The only way to truly fix the CPU spikiness is to spread scanning out across multiple frames. However, the engine wasn't designed with that in mind, and I don't have time to refactor it right now. r78 exposes a new option that lets you control the scanning granularity. Scanning is still triggered in response to game events, but won't occur any more often than whatever you set the throttle to. This won't eliminate the spikes, but will let you choose to make them more infrequent if you wish. My computer subjectively doesn't have any framerate hitches or visible difficulty running Energized with the defaults (although I did bump the default throttle to 3 seconds, up from 2).
This revision doesn't give you the ability to immediately trigger a scan via a click combination. My time is limited and I'll try to get that in later.
BTW: There is nothing at all random about when the scans occur. I assure you, scanning is always triggered by the game because something that Energized needs to know about happened. We throttle these things precisely because they happen frequently, and have the appearance of randomness. BuffEnough did not throttle anything, so this is quite an improvement.
I'm unable to reproduce this. The icon behaves correctly for me across reloads.
Thanks for your reply, I do appreciate all your input. :) Am typing this from my iPhone and will get back to the add-on this weekend.
Yes I know the minimap icon is provided by LibDBIcon-1.0. r14 was loading embedded in Energized, so there shouldn't be an issue. But there is.
When you have been CPU profiling/testing addons as long as I have, you gain a fairly good comparative basis to make claims on what is "high" and what is "low" ;). A regular spike of 4.6 CPU/second is high. On the upper end of the average tested mod spectrum. And for example, more than a full featured unit frame mod such as Shadowed Unit Frames uses. Etc.
Its not constant usage of course and fortunately its in-combat usage is very low. But high spikes like that have the real potential to produce lag for some people on lower end hardware. Its usage over time combined with other mods...all adds up.
As you mention, in terms of scanning options, regular 30 second scans won't do a lot of good immediately after a ready check for a raid pull (for example). One option there to avoid such issues (if possible in how you implement scanning in this mod) is to also allow a user-initiated scan by a click-combo on the LDB display or minimap icon.
The menu icon is provided by LibDBIcon. I don't believe I can solve the issue you describe, but will look into it.
Outside of combat, Energized scans inside a 2 second throttle. This occurs whenever a variety of things happens, including zoning, raid roster changes, pet events, and aura events. I can provide an option to turn these off and instead rely on a configurable timer alone, but I believe the add-on will be unusable when prepping for a pull. I also do not share your belief that CPU usage is high under any circumstance.
I am out of town the rest of the week, and cannot do anything with this until I get back.
A couple issues issues with r77 (didn't see before now as had stopped testing this). Tested with Ace3, LibTalentQuery-1.0, LibGroupTalents-1.0 & LibDualSpec-1.0 all disembedded, all other libraries embedded (CallbackHandler-1.0, LibDataBroker-1.1, LibDBIcon-1.0, LibQTip-1.0, LibStub), no saved variables at start.
1) It doesn't retain the minimap icon reloading the UI after enabling it. It disappears when you get back in-game. Have to go into options and check/uncheck Show minimap icon. Log out & back on, same problem, ad infinitum. This happens with AddonLoader active & whether or not you have Hide after being energized for (set seconds) enabled.
2) How about adding an option for the number of second between (out of combat) updates? Right now the update times seem completely random.
Every few ticks/seconds out of combat when Solo is checkmarked (testing alone), CPU usage of Energized spikes from 0 to 1.8 CPU/second median, Ace3 spikes from 0.775 (what it medians on idle alone) to 3.6 (for a Energized-instigated net usage of 2.8) & LibGroupTalents-1.0 "spikes" (not much) to 0.011. After this 3 mod/library spike for 1 tick/second, Energized & LibGroupTalents-1.0 return to 0 & Ace3 to 0.775. The embedded libraries in this test (see above) use 0 at all times standalone. That combined spike usage of 4.6 is really quite high.
The problem with this (besides it being high) is that the number of ticks/seconds between spikes appear to be completely random. Sometimes it happens 10 ticks apart, sometimes 6, sometimes 8 and so on. I assume the mod is doing its scanning during these spikes.
If it is scanning you/party/raid during these random CPU spike times, how about instead giving an option for a set time (on a slider) for when out of combat scans occur? Adjustable from say 1 second to 60?