That is not true. The new lib does not wipe mob data right away. But by default, it only keeps a certain number of entries, so that the total size stays at about 50KB (or 1000 entries?). If you install the lib as a standalone addon, you get actions to make it not save data at all, or to keep more entries (up to "all of them").
I would just like to remind everyone that to be able to see ALL configuration options for various frames, you MUST turn on configuration mode in PitBull.
I have having a major problem with my target unit frames. I am unable to view my own debuffs on the target. My party frames work just fine, but when i try to target someone in my party who has debuffs they do not show on the target frames. Does anyone else have this same problem?
I'd like to be able to turn it off as well, but for a different reason. I actually DO like to see the absolute hp values, however, I have a HUGE MobInfo database already established over the last year or so. With LibMobHealth-4.0 my MobInfo absolute values are overwritten by PitBull with "100%" until I start to damage the mob and it calculates the hp. Exiting the game and logging back in wipes any "history" of mob hp value (as I understand it LibMobHealth-4.0 does not maintain a permanent database) and the mob shows as "100%" again.
PitBull (or rather, DogTag) is hardcoded to choose LibMobHealth-4.0 first, then fall back on MobHealth3 or MobInfo. If you want to control this, you can remove LibMobHealth-4.0 from your system, although that's a bit of a pain if you use embedded libraries. Alternatively, you can install LibMobHealth-4.0 standalone so that it will save its data (which it can't do while embedded due to technical limitations).
I've implemented some of the requests for the VisualHeal module:
PitBull
- Added option to disable the VisualHeal bars for specific frame groups.
- Configurable colors and transparency for the VisualHeal bars.
- By default the outgoing heal bar will be opaque when not overhealing and slightly transparent when overhealing to reduce occlusion of other UI elements.
- By default the incoming heal bar will be slightly transparent to make it easier to discern from the other bars.
Completed: At revision: 61187
It also fixes this problem (although very few people disable the health bar on their unit frames...):
Quote from Aldamar »
Error occured in: Global
Count: 1
Message: ..\AddOns\PitBull_VisualHeal\VisualHeal.lua line 114:
attempt to index local 'healthBar' (a nil value)
Some info more: i disabled the Player UF health bar. This error happens when i heal myself 4 the 1st time.
Having a wow crash occur when I install Pitbull past version r60761. Occurs with the newest version r61187. I have the newest LibRockConfig lib. Only occurs when I access Pitbull's rock config page, I can access any other mod through rock without any problems. At first I thought my memory was going bad but I can recreate it repeatedly by accessing Pitbull's rock page and it doesn't happen in any other application, game or work oriented. I have reverted to r60761 for now.
Having a wow crash occur when I install Pitbull past version r60761. Occurs with the newest version r61187. I have the newest LibRockConfig lib. Only occurs when I access Pitbull's rock config page, I can access any other mod through rock without any problems. At first I thought my memory was going bad but I can recreate it repeatedly by accessing Pitbull's rock page and it doesn't happen in any other application, game or work oriented. I have reverted to r60761 for now.
That is strange. Can you verify that it happens *every* time with r60838 and never with r60761? Also, are you using embedded or disembedded libs?
PitBull (or rather, DogTag) is hardcoded to choose LibMobHealth-4.0 first, then fall back on MobHealth3 or MobInfo. If you want to control this, you can remove LibMobHealth-4.0 from your system, although that's a bit of a pain if you use embedded libraries. Alternatively, you can install LibMobHealth-4.0 standalone so that it will save its data (which it can't do while embedded due to technical limitations).
Hi Ellipsis,
Thanks for the post. I do use the embedded libraries, but I just manually delete the modules I don't want from my PitBull folder. Are you able to explain how to removed LibMobHealth-4.0? It doesn't appear to be a standalone module (located in the "libs" folder), and even when running the PitBulllod.sh to disembed libraries, I notice that LibMobHealth-4.0 isn't referenced in anyway. Thanks again for your time.
That is strange. Can you verify that it happens *every* time with r60838 and never with r60761? Also, are you using embedded or disembedded libs?
I went ahead and tried the versions after r60761, all of them crashed. I have not crashed on r60761 and prior. I'm using embedded libraries.
Aight I was bored so I stripped my interface folder bare except pitbull. It's not crashing when the mod is by itself. I'm going to add my other addons one by one (ugh) and see which one will trigger the crash.
I went ahead and tried the versions after r60761, all of them crashed. I have not crashed on r60761 and prior. I'm using embedded libraries.
Aight I was bored so I stripped my interface folder bare except pitbull. It's not crashing when the mod is by itself. I'm going to add my other addons one by one (ugh) and see which one will trigger the crash.
On the previous page I posted how I was getting this error after updating PitBull from 60731:
It turned out that Cartographer was out of date and this was the cause of the problem, even though the lua error pointed to my LibRockConfig-1.0 in PitBull. Go figure :P
I went ahead and tried the versions after r60761, all of them crashed. I have not crashed on r60761 and prior. I'm using embedded libraries.
Aight I was bored so I stripped my interface folder bare except pitbull. It's not crashing when the mod is by itself. I'm going to add my other addons one by one (ugh) and see which one will trigger the crash.
Let us know if you can isolate the conflicting addon. We do appreciate the time you put into it, and if you are able to find the culprit I will narrow down the cause of the crash and report it to Blizzard. :)
Let us know if you can isolate the conflicting addon. We do appreciate the time you put into it, and if you are able to find the culprit I will narrow down the cause of the crash and report it to Blizzard. :)
I found it! It was !VisualThemes_Rock Config. I'll let Kameril know. And no problem, I like figuring stuff out. :)
Thanks for the post. I do use the embedded libraries, but I just manually delete the modules I don't want from my PitBull folder. Are you able to explain how to removed LibMobHealth-4.0? It doesn't appear to be a standalone module (located in the "libs" folder), and even when running the PitBulllod.sh to disembed libraries, I notice that LibMobHealth-4.0 isn't referenced in anyway. Thanks again for your time.
LibMobHealth-4.0 is, as the name suggests, a library. It will be in the PitBull\libs\ folder with all your other embedded libraries. Note that it may be included with other addons as well, and PitBull will always use it if it's found, so I suggest searching your entire Addons folder to make sure there aren't other copies lying around.
You should be able to just delete the folder entirely without issues. Theoretically, an addon could embed it because it actually *requires* the library, but I don't believe that's the case for any addons (yet).
LibMobHealth-4.0 is, as the name suggests, a library. It will be in the PitBull\libs\ folder with all your other embedded libraries. Note that it may be included with other addons as well, and PitBull will always use it if it's found, so I suggest searching your entire Addons folder to make sure there aren't other copies lying around.
You should be able to just delete the folder entirely without issues. Theoretically, an addon could embed it because it actually *requires* the library, but I don't believe that's the case for any addons (yet).
Thanks once again Ellipsis. Deleting the LibMobHealth-4.0 folder from "/Interface/Addons/PitBull/libs" did the trick :D
Updated to PitBull r61196 and I'm seeing some very strange behaviour in the health bar and incoming heals bar:
- Take off gear and then put it back on to produce a health deficit. However, the health bar does not update to indicate a deficit - it's still full. Health text does update. I've seen this in player, target and party frames. It appears to be stuck at the level of health the unit had when the frame was created? For example, I lose some health but my player frame health bar doesn't change. If I then target myself, my target frame shows the health bar at the correct level, but if I heal myself the health bar in the target frame doesn't update.
- The incoming heals bar doesn't always show heals from other players in the group (with same version of PitBull installed) and sometimes shows as a bar which is too short for the size of heal incoming and too high -- overflowing the top and bottom of the actual health bar.
Reverting back to r60729 fixes the problem. Didn't try any other revisions in between.
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
-
View User Profile
-
View Posts
-
Send Message
Curse Premium-
View User Profile
-
View Posts
-
Send Message
Curse PremiumI pasted the text and got the confirmation line in the chat window - And what do i do now?
PitBull (or rather, DogTag) is hardcoded to choose LibMobHealth-4.0 first, then fall back on MobHealth3 or MobInfo. If you want to control this, you can remove LibMobHealth-4.0 from your system, although that's a bit of a pain if you use embedded libraries. Alternatively, you can install LibMobHealth-4.0 standalone so that it will save its data (which it can't do while embedded due to technical limitations).
PitBull
- Added option to disable the VisualHeal bars for specific frame groups.
- Configurable colors and transparency for the VisualHeal bars.
- By default the outgoing heal bar will be opaque when not overhealing and slightly transparent when overhealing to reduce occlusion of other UI elements.
- By default the incoming heal bar will be slightly transparent to make it easier to discern from the other bars.
Completed: At revision: 61187
It also fixes this problem (although very few people disable the health bar on their unit frames...):
Here's a pic:
That is strange. Can you verify that it happens *every* time with r60838 and never with r60761? Also, are you using embedded or disembedded libs?
Hi Ellipsis,
Thanks for the post. I do use the embedded libraries, but I just manually delete the modules I don't want from my PitBull folder. Are you able to explain how to removed LibMobHealth-4.0? It doesn't appear to be a standalone module (located in the "libs" folder), and even when running the PitBulllod.sh to disembed libraries, I notice that LibMobHealth-4.0 isn't referenced in anyway. Thanks again for your time.
I went ahead and tried the versions after r60761, all of them crashed. I have not crashed on r60761 and prior. I'm using embedded libraries.
Aight I was bored so I stripped my interface folder bare except pitbull. It's not crashing when the mod is by itself. I'm going to add my other addons one by one (ugh) and see which one will trigger the crash.
On the previous page I posted how I was getting this error after updating PitBull from 60731:
http://img175.imageshack.us/my.php?image=screenshot021208213051cz3.jpg
It turned out that Cartographer was out of date and this was the cause of the problem, even though the lua error pointed to my LibRockConfig-1.0 in PitBull. Go figure :P
Let us know if you can isolate the conflicting addon. We do appreciate the time you put into it, and if you are able to find the culprit I will narrow down the cause of the crash and report it to Blizzard. :)
I found it! It was !VisualThemes_Rock Config. I'll let Kameril know. And no problem, I like figuring stuff out. :)
LibMobHealth-4.0 is, as the name suggests, a library. It will be in the PitBull\libs\ folder with all your other embedded libraries. Note that it may be included with other addons as well, and PitBull will always use it if it's found, so I suggest searching your entire Addons folder to make sure there aren't other copies lying around.
You should be able to just delete the folder entirely without issues. Theoretically, an addon could embed it because it actually *requires* the library, but I don't believe that's the case for any addons (yet).
Thanks once again Ellipsis. Deleting the LibMobHealth-4.0 folder from "/Interface/Addons/PitBull/libs" did the trick :D
-
View User Profile
-
View Posts
-
Send Message
Curse Premium- Take off gear and then put it back on to produce a health deficit. However, the health bar does not update to indicate a deficit - it's still full. Health text does update. I've seen this in player, target and party frames. It appears to be stuck at the level of health the unit had when the frame was created? For example, I lose some health but my player frame health bar doesn't change. If I then target myself, my target frame shows the health bar at the correct level, but if I heal myself the health bar in the target frame doesn't update.
- The incoming heals bar doesn't always show heals from other players in the group (with same version of PitBull installed) and sometimes shows as a bar which is too short for the size of heal incoming and too high -- overflowing the top and bottom of the actual health bar.
Reverting back to r60729 fixes the problem. Didn't try any other revisions in between.