Authors CurseForge

Just wondered if anyone could provide some light on CandyBar? In case I wanted to use it in a mod :)

No light for you!

Well, look at the bars.lua file in bigwigs, or look at the code itsself in CB. I'll harass ammo about some API documentation or something maybe :P

Thanks to Fritti:

http://wiki.wowace.com/index.php/CandyBar-2.0_API_Documentation

-Ammo

SetCandyBarTexture(name, texture)
Sets the texture of the CandyBar.

[edit]Args
name
string - name of the bar
texture
string - name of the texture that will be applied to the bar. If nil, the texture will be reset to the default.

It's not possible to pass nil as second arg as argCheck expects a string and you don't check if texture is present before doing the check.

Would be nice if that could be in future versions.

EDIT:
Also :SetCandyBarTimerTextColor does require a colortable instead of a string as stated in the wiki.

flyspray plix!

-Ammo

I'd like to suggest a slight addition. The ability to specify a function to be used in calculating the bars value with time.

I have a diff file with proposed change:
http://www.gwief.com/files/candy.patch

As to why:
I disliked having bars overtaking eachother etc, I'd rather have a longer bar for longer cooldowns etc, just a linear expansion would be un-usable. Hence with this you can use a logarithmic function. where if 2 cooldowns are in the same place they will finish at the same time regardless of the total cooldown.


(a hacked cooldowntimers with log(time^3) used in calculating the bar length and the current bar value)

I would love these style bars as an option in bigwigs etc :)

Damn that's ugly.

-Ammo

Quote from Ammo »

Damn that's ugly.

-Ammo

QFT.

Here is an example of this not working well:

Bar 1 (10s duration:
|==========|
Bar 2 (2minute duration:
|===================================================================================================================|

You should remember (especially on bosses like Noth) there are bars for blink (relatively short) and a bar for teleport. Your idea would make bars have stupidly small scales in order for them to fit on people's screens or scales which just go off the end of a screen.

Edit: I read you wanted to use a log scale, in which case I refer to my QFT with Ammo.

would it be possible to make a bar clickable .. perhaps by assigning a callback function or something like that ? :)

I've already begun work on that, but it's BigWigs 'week' for me right now. So CandyBar will have to wait till this weekend, just like oRA2 has to wait. Don't worry, it's on the todo.

-Ammo

Hence with this you can use a logarithmic function. where if 2 cooldowns are in the same place they will finish at the same time regardless of the total cooldown.

That's a nice feature IMHO that could be nice as an option?

If someone wants to do that in their addon, then they can use the SetWidth() function in CandyBar themselves. It's not that hard, but I will not code this into the lib itself.

-Ammo

I want all my bars to look the same!

I see you've got

ourpath = "Interface\\AddOns\\"..ourpath .. "bar.tga"

on like 1217 of CandyBar-2.0.lua

Is there any way to easily change this without going through every single CandyBar folder and replacing the tga?

There should be a mod to standardize artwork accross the entire UI or something.

As an author of a CandyBars addon, and a user of several CandyBars addons, I think it'd be nice if we could try to come up with a system that allows for standardized configuration of CandyBars appearance.

As it stands right now, the amount of configurability and default settings for addons like oCD, CDT, Chronometer, Antagonist, etc. are all over the map, and for each of these addons users must learn a new set of commands to control the appearance of the bars. In some cases, there is simply no way apart from editing the code for the addons to get a uniform appearance from all of the bars.

So I've been trying to think of some potential implementations for this - here are a couple of my ideas.

• A "CandyBars options" table stored in the library (or accessible via an accessor function that could change some parameters such as the location of the variable in which to store settings). Client addons would retrieve this table and inject it into their own options table and/or other configuration mechanism.
The CandyBars options would be pointed at a table variable to modify - probably stored in the addon's AceDB profile. A default table would also be retrievable from the library to allow a uniform default appearance.

The options table would be passed as a whole to a CandyBars function rather than using individual accessors. This would allow addon/removing/changing members of the options table without each addon author having to go through and change how his or her addon creates bars.

Sharing configurations between CandyBars addons would still need to be solved (although it would be easier to configure them individually to the same appearance, with a uniform configuration UI).


• A CandyBars configuration management utility/addon. Addons based on CandyBars would not actually set any of the CandyBars appearance options themselves; instead, the options would be arranged into CandyBars option-sets by the configuration management utility, and addons would select which option set to use by name.
This allows for more easily sharing configurations, although I'm sure there are some downsides I haven't yet foreseen, as I didn't spend as much time thinking this one through.

Textures would be the other issue, and they seem to be a bit more complicated (as we seem to have found from the old default texture which had to be removed so that people stopped getting transparent bars). Maybe haste's new SurfaceLib can help with this one.

As CandyBar is a library and can be used in numerous ways there can and will be no real way of making sure every Candybar looks the same. Sometimes the bars need to be embedded in a frame of a certain size etc. For instance Candybars used in oRA2 cooldown are slightly less width than the default ones. Forcing every candybar in game to look the same way will cause more trouble than it would solve.

Getting a uniform appearance for all bars is easy: Don't touch the settings per default. The default look is the default look. At the moment Chronometer is the only candybar addon that has a different default look, maybe you should start by not changing it per def.

I can understand where people come from when they want a uniform look across all their addons, that's why candybar has an in my eyes sane default. Giving the user options to change the look depends on the author of the addon that uses it. Changing the look of all candybars to one layout from the library itself will never happen because that can and will break the look of another addon using the bars in for instance a frame of a certain width etc.

-Ammo

Error or working as intended?

ct = AceLibrary("CandyBar-2.0");

ct:RegisterCandyBar("boo", 10, "text");
ct:StartCandyBar("boo");

-- On another event handler, mine was @ UNIT_SPELLCAST_DELAYED

-- Some really evil mob hit me and delayed my spell for 110s
ct:SetCandyBarTime("boo", 120)

Expected result: the 2 minutes bar should vanish after 2 minutes.
What it does: sets the running bar to 2 mins and vanishes after 10 seconds.

I used this logic for aUF_CastBars (gonna rename mEnemyCastbar, it's not on enemy frame only anymore, and 100% tied into aUF), wondered why everything was wrong if a mob hits me and extend my casting time, and came to the conclusion that CandyBar-2.0 didn't take the new cast time in account.

Error and fixed :)

-Ammo

Lines 1279 and 1280, containing

		local _,_,ourpath = string.find(debugstack(), "\\AddOns\\(.-)CandyBar%-2%.0%.lua")
		ourpath = "Interface\\AddOns\\"..ourpath .. "bar.tga"

can be safely removed from the library.

I'm getting an error from the 2 lines listed above, and was wondering what I can do to prevent it (short of removing the two lines from file).

The specific error is caused because debugstack() returns nil, resulting the in 2nd line failing.

This error only occurs if my addon is the first to load the CandyBar library, so I have the feeling I'm doing something wrong. But for the life of me I can't figure out what...

ourpath is not used anymore. These two lines are a leftover from before the introduction of SurfaceLib and should be removed.