I find that it doesn't work until I hover over said nameplates upon which they promptly disappear.
I believe that is because until you mouseover the nameplates, Aloft doesn't know anything about that unit except its name. It doesn't know that it's a critter because it needs a unitid to get the creature type.
It could remember based on the name, but then I think you run into the problem of players, pets or non-critter NPCs named the same as a critter.
It is a bit annoying Blizzard don't allow per default to not show critter/neutral nameplates.
yeah, blizzard's underlying nameplate implementation almost seems like an afterthought... which is why Roartindon implemented Aloft all those many centuries ago... but of course while critters are not explicitly called out, many other sorts of filtering is supplied by Blizzard in the Main->Interface->Names menu. better than nothing, anyway :-).
the feature i wish i had is being able to adjust the range at which nameplates become "live" (i.e. show a health bar, use for interaction, etc). i would like to be able to turn off friendly nameplates and so forth, and increase this "live" range, when in PvE instances. it would probably do bad things to my framerates, and would need some tuning of the settings, but right now it seems you need to be almost within melee distance for the "live" effect (and i tend to play ranged DPS classes/specs).
alright, i have dug into the HealthBarColor tag issue.
it looks like this is "working", insofar as Aloft (since WoW 2.3) is able to determine class information for hostile/NPC units.
the problem lies specifically in the underlying mechanism for identifying class for hostile/NPC units. basically "aloft can't do that any more". and even for friendly players, a mouseover or target action is required.
so, if i am misuderstanding how this is "broken" (in terms of collecting the $10 reward via paypal :-)), please clarify. i am not interested in the reward, i just want to make sure that i fix whatever is broken, if it is fixable. as well, i am new to Aloft as an implementation, as well as new to LUA and the whole WoW API (and its conventions and limitations), so if i am stating the obvious here, don't saw my head off :-)
from testing and digging into the code:
nowadays, Aloft can try to grab all the data it wants for hostile/NPC units via the "mouseover" and "target" unitids, but then either the underlying Blizzard nameplate never goes "live" (i.e. never changes to a bar, such as for unflagged players of the opposing faction; this leaves Aloft with nothing to do), or it can't associate the data accurately with its own nameplates (because unitids and unit GUIDs cannot be mined directly out of nameplates; they must be associated circuitously via unit name, which for most NPCs is not unique).
i suppose i could go through the gyrations to track class on pets and "town" NPCs (vendors/etc). they would have unique enough names to do the association. but what would be the purpose?
it appears that the nameplate "color hostile by class" option is only meaningful now on flagged players of the opposing class. the tooltip for this option in the Aloft options menu does actually mention "players", but the basic option label text could probably be more clearly worded. i will try to spend some time in a BG in the coming days and verify this, but the code appears to be there in spades to do all of the necessary stuff (it is the same code that tracks friendly players, its just that unflagged hostile players don't have nameplates so there is nothing for Aloft to do with the information).
class coloring of friendly nameplates, and the associated HealthBarColor text tag, seem to be fine, but again: it requires a mouseover or a target action before Aloft can collect class data and the nameplate color (and effect of the HealthBarColor) changes... except for group-members, in which case it is automatic (collected proactively when the roster changes).
Yes, yes. The HealthBar itself, I've set it to black when the data is 'unknown'. However, after a mouseover, target, or whatnot, the bar becomes the right color and stays the right color forever more, because it's collected into a database. Once it's in the database, Aloft pulls from the database to determine the color of the bar. The bar itself always displays in the right color.
The HealthBarColor tag, the actual text on the bar, does not. It could be a paladin, and it's known that it's a paladin, and the bar is pink, as a paladin should be, but the text is some random color, like green, white, a color from one of the other classes/npcs, etc. When the bug occurs, it's like it's picking some random healthbar color, possibly the color from the last bar it calculated for, rather than from the color of the bar it's on.
I've provided a few screenshots below. I can even record a short video if you want. In short, the color of the bar itself works perfectly, it's only the tag, and therefore the text, that can sometimes display incorrectly. It seems to happen when displaying several bars at once.
The error that occurs:
Date: 2008-09-03 12:02:54
Error occured in: Global
Message: ..\AddOns\Aloft\AloftTag.lua line 106:
attempt to perform arithmetic on field 'healthBarR' (a nil value)
[string "WOWX:ErrorHandler(...);"]:1: in main chunk
A couple npc's. Working perfectly. The only text that is not the same color as the bar is the number for their level, and health (if shown). However, this is because it's using the 'originalhealthbarcolor' tag, not the 'healthbarcolor' one, which I only use on friendly players.
Attachment 2: The Draenei Mage is working right. Their name and their race match the healthbar. Everyone else has some random designation, not the same color as their bar. The mod gets the color of the bar itself right, but is assigning a random color to the actual text, although the text is intended to be identical in color to the bar itself.
Attachment 3: It's not always broken. Here's an example of it working perfectly. The same few characters, after I waited a bit, walked away so the bars went away, and came back.
The 'level' tag I'm using: [Level][Classification:Prefix(" "):OriginalHealthBarColor][CreatureType:Prefix(" "):OriginalHealthBarColor][Race:Prefix(" "):HealthBarColor:IsFriendlyPlayer][Race:Prefix(" "):OriginalHealthBarColor:~IsFriendlyPlayer]
The 'name' tag I'm using: [Name:HealthBarColor:IsFriendlyPlayer][Name:OriginalHealthBarColor:~IsFriendlyPlayer]
The 'comment' tag I'm using: [TargetName:Surround("Target: "," "):HealthBarColor:IsFriendlyPlayer][TargetName:Surround("Target: "," "):OriginalHealthBarColor:~IsFriendlyPlayer][Comment:OriginalHealthBarColor][PetOwnersName:Suffix("'s Pet"):OriginalHealthBarColor]
Just plug in the same tags I'm using and you'll see the bug occur. Please fix!
Just plug in the same tags I'm using and you'll see the bug occur. Please fix!
i will do exactly that: plug in your tags and take a look. i will get back to you here when i have some analysis done.
alright, encounered the problem in testing something else (i.e. arithmetic on nil health bar color values). i tracked it down to what appears to be non-firing of nameplate hook functions (guessing its an intermittent Blizzard bug, but i don't know enough). i applied a fix for that (specifically pulling in health bar colors on demand when they turn up nil), and had no further problems. applied your tags (name/level/comment), went to a large city full of friendly players, and had no further problems...
well, except with text update timing during combat (revealed by your tags targetting functions, yet another bug in Aloft), but that is not specific to the HealthBarColor tag(s) :-).
i am in the process of cleaning up a few things, and want to do a little more testing (PvP in particular). then i will roll the Aloft code into the SVN repository i have waiting at WoWInterface. i will post here and start a thread there when i have a "beta" release ready. you can verify this fix.
alright, Aloft (reincarnated) is in BETA at WoWInterface. i am hosting the SVN there as well. once i understand how WoWInterface manages their SVN repository a little better, i am going to go ahead and open that up for general checkout access (never did manage to get SVN access here at WoWAce).
folks here, please feel free to try it out, and check and see if your favorite bug has/has not been fixed. let me know here, or at WoWInterface.
nice to hear this is still being developed. maybe i haven't set it up properly, but is the sheep timer active? i could swear it turned it on, but i don't believe i've ever seen any sheep timer gizmo.
from a pure pvp standpoint, i think it'd be awesome to incorporate a dr timer. i had posted before about the idea of connecting to other mods as a means to avoid having to write whole frameworks of redundant code. i have a dr timer that makes its own bars (dunno the name off hand) but it would seem possible to hook into that somehow with an aloft module and attach the bars to the appropriate plate. also, sorrentimers is a great mod for sharing casting info with fellow team members. again, it makes its own bars, but connecting them to aloft plates would be awesome.
my dream would be to see that my fellow mage is casting a sheep on the warrior we're going up against (i'd see the mage's polymorph castbar on the warrior's plate -- this data is avail from sorrentimers). once it goes off, i'd see how long that warrior will remain sheeped. once the sheep is over, i'd see when dr for that sheep would be up.
all that is available with seperate mods, but they put the data in their own locations which isn't always very helpful. i like to keep my eyes on the playfield and not search my ui for information.
As long as you don't have a hunter who named his pet after himself or a teammate, it isn't really a problem, as PvP opponents have unique names, and names are one of the few things you can get from a nameplate. I'd rather PvP-specific stuff didn't find its way into Aloft though. A third-party/external module is fine, but as I don't do arenas or battlegrounds, it'd just be one more chunk of code getting loaded into memory that I don't need.
yeah, if you lose range on your target or he's off screen (polymorph doesn't need to be in front of you) you don't see that timer. but if your target is in range and on screen, you do. which is better than it never being seen.
the way aloft is designed, there are many, many modules that don't load unless you activate them. there are core modules and optional modules as part of the base distro. adding a few pvp modules could be done as a totally separate download. most of the modules i don't even enable because i don't need/want them. pvp specific modules would be in the same boat as all these other modules.
Yes, but even if you aren't using a module, because the file is inside Aloft's folder and referenced in Aloft's TOC, it's loaded into memory whether or not you intend to run any of its code. ;)
hmm...yeah, i guess that makes sense. still, i don't see how a pvp module would be any different from the dozen or so other modules that don't get much use except for specific instances. maybe they all should be reworked into separate "packs" or even totally separate addons to reduce load time and memory footprint.
Yeah, it's fairly common to see people posting "OMG ALOFT USING 2MB MEMORY WTF". I think splitting off some of the special-interest modules -- such as the CC timers, aliases, and comments -- into external modules would be great.
- i will check out the polymorph module in the next day few days and make certain it is still functioning properly (my mage/jewelcrafter needs to do 2 more rounds of shattered sun offensive dailies to reach exalted; i need to finish that faction grind :-).
- the healthbar and the castbar are supplied by Blizzard, as frames; Aloft just tweaks them for texture/etc. but Aloft is able to tweak the healthbar color (color it by class for instance), so i expect the cast bar color could be tweaked similarly. i will look into this.
- separating Aloft modules out into separate addons sounds like it could be a good idea to me, but understand that there are a large number of these modules; it could end up looking like Grid or Pitbull3 with no trouble whatsoever. there will be people who want mana/threat text tags but not bars, and maybe even vis a versa, so i am at a loss to see a way to chunk functionality at a coarser granularity than individual modules. i suppose only those folks who want "everything" would end up being nickled/dimed to any great extent, but still, it could get ugly. nevertheless, i will give it some thought.
right now, i have fixed a few bugs and am working on getting something up that will run on WoW 3.x (WotLK), so that any teething trouble can be sorted out before expansion release.