Just wanna say I loved pitbull 3 and used it all the time recently I have upgraded to pitbull 4.0 and I like it, but to set up raid frames I feel like a monkey fucking a football its that hard. I finally setup 10 and 25 man raid frames for my pally saved it and started playing my rogue. I logged back on to my pally a month later and what do you know I lost all my raid frames for a 10 man all I have is my party showing. Al i ask is please make raid frames a little easier to setup I like checking 10-man set-up or 25-setup and being able to set it up the filter crap is retarded and useless I shouldn't have to choose 50 times that I am setting up a 10 man raid.
There are other less flexible unit frame addons out there for you to use, with far fewer configuration options. Perhaps you would prefer one of those.
I was speaking more along the lines of how the addon select screen's checkmarks work, ...
The "irrelevant, but enabled" and the related "partially enabled" control paradigms can provide some very powerful results, but they tend to become confused with one another easily. They usually require a visual hierarchy or textual cue to pull off successfully.
Blizzard can get away with this in the AddOn List screen because they provide the extra visual cue next to the addon's name saying "Dependency disabled" in bright yellow text, AND it lists the dependencies in the tooltip for the addon's checkbox.
I agree about the disabled vs. hidden options aspect being difficult (and confusing). Since the dependencies involved are quite complex, and since there are no easy solutions to laying them out with appropriate visual hierarchical cues within the limitations of AceConfig, users will become confused one way or the other.
However, which is potentially more disconcerting to a user: An option the user expects to be there and can't find at all, or an option the user expects to be there, but can't change?
My suggestion would be to disable the option, but leave it visible. In addition, when you disable the option, add an explanation to its description (shown by default in a mouseover tooltip) detailing why the option may not be available. (.. "Option Y requires Option X to be enabled/does not apply when Option X is disabled.")
This is a design principle that has worked well for me in applications with ridiculously complicated dependencies among their settings. After all, you can't tell the user that an option they expect to see doesn't apply if they can't see it! :)
Edit: A special concern about hiding options is that it can cause remaining options to reflow. This can result in the options that are actually there not being in the place users expect to find them.
Some of the confusion results from the fact that the word "group" can refer to many different aspects of the configuration. I honestly can't think of a word that better describes this aspect, however. "Which group do you want to appear in this group named Party?"
Would users understand it if they were called "grouping templates" or "collections" something silly like that instead? So that when they read the labels on the controls, in their heads it reads "Which group do you want to appear in this collection named Party?" "Which layout should apply to this collection named Party?"
Edit: I see someone in a ticket referred to them as "frame groups." That might be a good alternative, too. "Which unit group should appear in this frame group named Party?"
Noticed something last night (using PitBull4-v4.0.0-beta3-79-g0f135b9). When in a vehicle, the in-combat icon wasn't going away as soon as I left combat. It did a couple seconds later. Perhaps there is some throttling going on? As I said, this is in a vehicle, so that means the player frame becomes the pet/vehicle frame, and that's the one I'm talking about.
Not sure if it's a bug or if I did something wrong, which is why I'm posting here before reporting it as a bug via ticket.
Were you (or your vehicle) engaged in PvP combat (Wintergrasp, SotA, IoC, etc.)? If so, you don't actually leave combat until several seconds after your last action. I've seen instances of my pet or vehicle leaving combat before or after I do in PvP.
Yes, I remember the origin of the house-pet named addons a few years ago, and even made a minimap border texture with cute little chinchillas on it for Chinchilla. Calling these unit frames "dog-themed" just seems misleading. I think the notes used to read "Unit-frame addon of awesomeness. *WOOF* It'll bite your face off!" or something to that effect. Ironically, that description is probably more accurate than "dog-themed."
I'm curious as to why the AddOn List description (TOC ##Notes field) of PitBull still says: "Dog-themed unit frames. Woof. Arf. Yip." The only thing about PitBull that has ever been particularly dog-themed is its launcher icon texture.
Before I open a ticket, I wanted to ask if there is any obvious reason why with the new bar coloring options, "Color NPCs by hostility" does not appear to work with "Blank space" bars. (In addtion, the "Color by hostility" option has no effect on "Blank space" bars for units that are NPCs.)
Hello, I've opened a thred in the help forum and nobody answered, I've read a lot in these forums and I haven't got any answer to this but I did find some questions related to this, sounds weird to me. Well, I'm using Bartender 4 and I wondered how could I change the macro text font, if it's possible. Is it via Lua or should I install some additional addon...?
This thread is for questions regarding the PitBull 4.0 Unit Frames addon. You'd be better off asking in the Bartender 4 thread.
There are a couple exceptions to this:
UNIT_SPELLCAST_SENT which happens only for your own spell casts is always watched. We save a couple variables. This is necessary because of the auto-hide cast bars in PB4. Those cast bars don't exist until the unit starts casting and as a result neither do the texts. The information given in that event is not available any other way, you miss the even it's gone forever.
I've often wondered why these bars get hidden completely while not casting. Wouldn't it be unobtrusive enough to change the cast bar's color to match its background and set it to full, so it can register for the event directly? This way its anchored texts would also always be shown (even if you set the text to be some whitespace character) to register the event.
Also, this does not account for instances where i would parent the casting text to an element other than the cast bar.
I'll try and get SimpleTexts finished this weekend. I flushed out a start on it but only bothered to get Name working. Shouldn't take too terribly long. I'll probably implement all the default DogTag codes as text formats in it. Which if you're like me you can pretty much use it to replace all your text.
That's exactly what I did. I created replacement versions of the default codes. For testing purposes, I decideded not to register events or use timers. I only used placeholder text for text elements that were likely to require updating more frequently than a frame would be recycled.
One thing that I found caused a couple of issues is when I gave the default text names the same names as the default texts used by the DogTag module, so I simply prepended all my default text names with "Test-". I also removed the configuration settings for "custom" codes from my module.
Well, it was actually really easy to make a test texts module to use alongside or instead of DogTag-3.0Texts. With event-based updating disabled, it uses about 10-15k while soloing and 30-40k in raids, depending on the number of texts used and the number of units active.
Are there any suggestions as to what might make this module suitable for use in testing scenarios? Should I register for events and perform appropriate frame updates based on those events? Without adding this functionality, things like current health, power, reputation, experience, and most notably, all casting info will not be available as texts. Is it desirable to enable updates when trying to measure the performance or stability of other modules, or would it be best to stick only with static texts?
Speaking of custom modules, is it possible for me to actually register a custom module TYPE and then create a custom module of that custom type? For example, could I register a "Decorator" type that behaves similarly to an indicator but is implemented slightly differently? I could then create a number of independent "decorator" modules with varying features.