eXtreme Unit Buttons 

XUB doesn't allow separate lines in the macro, but I will investigate the #show option.

The macro system is pretty dumb. It simply issues the command without any kind of analysis of what the macro is. I think the action button system does some analysis as to what the macro is and can make more intelligent display decisions.

I'm not prepared to write this kind of logic, however, I have been thinking about a new set of changes that MAY make the need to write macros like this one obsolete. It's still pretty preliminary and is at least 2-3 versions away.

Fridmarr:

I don't use XUB myself (I'm a stubborn keyboarder), so I can't test, but this might work:

#show Righteous Defense
/cast [target=target,help] Righteous Defense; [target=targettarget,help] Righteous Defense

That #show forces the game to display cooldown info about that spell instead of what it *thinks* it should show. It's helped with some of my other macros, it may help in this case.

I have a custom macro button tied to my target frame for calling Righteous Defense, which has a 15 second cooldown.

I've defined the macro as...
/cast [target=target,help] Righteous Defense; [target=targettarget,help] Righteous Defense

Basically it casts on the current target if it's friendly or my target's target if it's hostile.

When I use it from xub macro button, the button does not show the cooldown, but if I make a regular macro and add it to a standard toolbar, then it does. Is there anyway to have my xub button also show the cooldown?

I've run into this before, but not with WOW. Some user says, "We'd never do that" and within six months they'd come up with a reason why in some cases they'd do that. So I have learned to create code that is not constraining. There are no "special case" conditionals in the code that test to see if this is a particular character type or not. I didn't want to add constraints about the settings for OPTIONS either. While it's true that most gamers have the same configuration across all their toons, I'm the exception and don't. Why should I create something that constrains myself? Anyway, the approach allows all gamers to use the mod and handle the special situations too.

What if I implemented a SAVE configuration option that made a copy of the variables and placed them globally? Then a corresponding LOAD option to pull them from the global area into whatever character. It doesn't mess up other existing gamers and gives you a centralized location for all your toons configuration.

I'm considering this as part of a solution to a different problem, which is helping the first time user configure the mod. If I included a default global LUA file (which was installed), then a "/xub load default_priest" would effectively initialize their environment with a typical "priest" configuration. For yourself, you could, on one toon, say "/xub save ..." then on another server with another toon type "/xub load ...".

Comments?

The (unsupported) floating frame has potential; with more such frames, the ability to control their opacity and to lock their locations, you'd have the function to add arbitrary groups of buttons pretty much without limit and wherever needed. One observation: whether or not it's been triggered by my using it on one character or not I don't know, but right now the frame box displays for any character without a profile.

You also don't currently support, as far as I can see, the idea of an "empty" profile - i.e. I can't tell the mod that it has nothing to load, so it throws an error on startup every time if nothing exists.

I'd be fascinated to know how many people actually use completely different mods in that manner. Of the mods I've looked at, you seem to be the only person supporting that, but then again I don't claim expertise, and if that's what you're aiming for, fine. As for having things in text, though, the difference between one approach and the other is simply having WoW save/load your variables in/from one .lua file per character or in/from one .lua file for the mod as a whole. Being able to cut and paste text within a single file is very little different to doing so between files, and arguably far easier to manage if you need to copy sections rather than the whole thing, so no issue there.

Anyway - all of this has been just a personal reaction to the single aspect of the mod to date that I really disliked. Feel free to ignore it or not as you please, naturally. I suspect that if you'd included a load/don't load option by toon as well (as, say, Auctioneer does), I'd not even have noticed until the game corrupted my saved files (as it has on at least three occasions in the past) and I found that I didn't have a backup. For me, the idea of having to manage individual configuration files, in different locations, for every one of my 20+ toons is, in all honesty, off-putting, and a significant inhibitor to using it extensively, even if in reality I can handle the backup issue by copying the whole of my WTF directory now that I understand the issue - but maybe I'm unusual in that respect.

The key reason to store ALL the variables on the character was to eliminate the issue of one toon having a completely different configuration (unit frames et al) from another toon; such as a partner/sibling playing on your account.

Also, because the specification is all text, you can copy-and-paste it from one character to another by placing it in a separate text file. Issues with sharing between characters, albeit with text, is working now and requires no additional work.

I investigated the ability to load specifications from files and it is very restrictive. If it was possible to read/write files I might add a utility, but right now it is too challenging.

That being said, I don't like the fact that I have to specify so many variables, so I am going to change it in the future. I may consider the name value pairs in a different way.

The buttons will eventually load .. there is a 30-second pause from the time the game engine starts before it shows up. I'm investigating different ideas to minimize this time and as such the problem you are reporting should resolve itself.

In all honesty, having thought about it, it may well be something you're not going to do. Anyway (and let me add up front that I'm not an LUA programmer; whilst I've tweaked mods, I've never written one myself, so I'll readily confess that I'm guessing a little based upon the code of some of the ones I use).

The difference of approach is to code for multiple characters rather than a single one. As far as I can see, your .toc file uses SavedVariablesPerCharacter, whereas many mods simply use SavedVariables, which I guess is what puts it into the common x:\World of Warcraft\WTF\Account\<account name>\SavedVariables folder (so still under WTF, but in a single location rather than one location for each character, which makes the whole thing easy to back up - to give you an idea of the difference, I have roughly 20 toons spread over 4 or 5 realms, so backing each one up would be a nightmare, and is pretty much a non-starter; backing up a single directory, by contrast, is downright trivial).

To support multiple characters, the variables are extended to reflect the presence of multiple toons - either by toon alone (using a name constructed of the toon and realm names together) or by toon and realm.

GroupButtons, for example, had a saved structure along the lines of
GB_Settings = {
["Toonname1::Realmname1"] = {
....
},
["Toonname2::Realmname2"] = {
...
},
}

By contrast, CharacterProfiler has
myProfile = {
["Realmname1"] = {
["Toonname1"] = {
...
},
["Toonname2"] = {
...
},
},
["Realmname2"] = {
["Toonname3"] = {
...
},
},
}

Clearly more scaffolding is needed to handle that extra structure, and equally clearly it's the sort of thing that's easiest to do if you design for it from the start, because going from a simpler structure to a more complex one has the potential to hit just about every line of code multiple times - with plenty of opportunities for bugs by consequence. Probably non-trivial and probably not for the faint-hearted unless you're lucky in the approach you've taken to date and the shape of your existing code, I guess. Ah, well.

(Edited for clarity)

Hi,

With v1.3 my NaturesSwiftness button doesn't work on the target unit or raid unit. It is non-clickable. Only clickable on the player unit.

FYI, after d/l and installing version 1.3c, the first time I did a 'Verify' I got this error...

Repeating the 'Verify' a second time, the error did not show. I didn't change my existing config settings from 1.3b before installing 1.3c and doing a 'Verify'.

EDIT: Additional Info. When my char first logs in, none of the buttons appear. If I try to do a "Verify" at this point, I get the error I mention above. If I wait ~10 seconds, the buttons appear, and then when I do a 'Verify' I don't get the error. However, on another char, I have some 'pet' entries, even though my char does not have a pet, and I get the same error in this case, except for 'pet' instead of 'player'.

It seems like if the bar is not visible, hitting the 'Verify' button will generate an error, but once the button is visible, the error goes away, for 'player' and 'pet' at least.

Great Job Elenesski, Buttons working great for me

big thx

Hmmm... I was under the impression that AceGUI (is that what you mean? The toolkit for building GUIs?) hasn't been worked on for quite some time.

You might want to consider this: http://www.wowace.com/forums/index.php?topic=4812.0

(I have nothing to do with these, just perusing the forums)