I would like class icons very much as well. Is this in Aloft (yet)? I haven't been able to find the option for it.
i don't think Aloft does this. it does boss icons and raid target assignment icons, but not class icons.
having said that, this should be very doable, a straightforward clone of the functionality for one of the other icon modules. just need to dig the paths to the icons out of Blizzard's MPQ gobbledigook. i will put this in my list of features to add.
cool, so it sounds like you've figure out some controls to help eliminate the haphazard layout feel, yeah?
also, i was doing some pve the other day and i had this weird threat glow bar thing show up at what seemed like it might have been the original blizzard scale (much larger than mine). it was yellowish (which is consistent with my threat glow color) so it might have been mine mis-scaled or it might have been a different element that i hadn't configured yet... it seemed to go away after a few seconds -- either because threat status had changed or because it was a blizzard frame that realized it shouldn't be on...
yeah, Aloft supplies glow textures, and the default Aloft settings are designed to lay these glow textures out around healthbars in a clean way.
but if you have customized Aloft at all (changed healthbar size, etc), the settings won't necessarily match everything up any more. you will need to re-adjust these glow textures. play with the size/position options under "Nameplate Glow" and if you have threat bars enabled, also under "Threat Bar>Threat Flash" as well.
packing height/width would make sense... but i have not noticed that it helps.
actually, the original poster is quite correct. packing height/width (under "Frame" options) does indeed very effectively alter how the game tiles nameplates.
it also appears that making the healthbar itself smaller has an effect, until the healthbar area is reduced to dimensions similar to that of the underlying native Blizzard bar-style nameplate, at which point further healthbar area reduction has no additional effect (i.e. empty space is appears between tightly tiled nameplates).
a packing height/width of 0 will allow the game to tile nameplate healthbar areas immediately next to each other. negative values will permit the game to make healthbar areas overlap. a small packing height/width will permit a little space around the nameplate, so that any text or other elements that appear outside the healthbar will have some room to display without being overlapped by the healthbars of other nameplates.
the plain height/width settings under "Frame" options affect the extent of the background/border region, as it extends beyond the healthbar area. this background/border region appears to overlap freely with other nameplates, independently of the packing dimensions.
under "Frame" options, i am going to tweak "my" version of Aloft to permit small negative values for the packing options (so that some overlap can be enabled, if desired), and small negative values for the plain height/width settings (so that borders can be inset slightly, leaving no empty space between the inner edge of the border and the outer edge of the healthbar area, if desired).
Using 188.8.131.52 I noticed that, in the Visibility options, changing the "Friendly pets" option doesn't do anything, instead friendly pets go under the "Friendly NPCs" option. Also, critters' nameplates aren't hidden when disabling them, they are hidden if you disable "Neutral units", though.
yeah, this has been fixed. i beefed up data collection to insure that Aloft would be able to determine what constitutes a "pet".
with stuff like this, in some cases it can depend on an associated text tag (like "[IsPet]" or "[PetOwnersName]") being incorporated in a text field somewhere. otherwise, Aloft will consider the supporting data for these text tags to be "unused" and it won't bother collecting it (which can mean it is unavailable for other purposes as well).
in that case, as far as Aloft is concerned, pets would not be pets, they would be indistinguishable from generic NPCs and their visibility would be controlled as such.
anyway, its always possible there are defects in my "fix" to this... so try it out (strip any pet-related text tags out of your text fields, and see if things are properly controlled by "pet"-related visibility options.
I'm guessing that it's only possible to link in to the blizzard bar nameplates, rather than linking in to the name display (sorry, not sure what terms to use) which I use that isn't clickable, but does scale with camera distance and does not move in relation to the character model.
you know, i am not certain about this, specifically. i suspect there are at least *some* graphical elements present under "WorldFrames" that could probably be identified as parts of these purely textual nameplates.
my real concern, however, is in the runtime overhead of replacing all of these text nameplates, taking control over them in an addon, and engaging in all the processing effort required to scale them in real-time to generate a proper perspective effect, and so forth, via a LUA-based addon. even if this were "technically feasible", it would probably be fairly undesirable.
personally, i have a sneaking suspicion Blizzard already thought about this, in conjunction with their own native bar-style nameplate implementation, and steered clear (opting simply to limit the range at which the fixed-size bar-style nameplates appear).
the range of bar-style nameplates is fairly short, for instance, not really useful for ranged combat, and the user cannot control this range (as far as i know, not even by poking a WTF value into a file under the covers somewhere)... i think it is almost certain this is a result of "efficiency" concerns.
...they're really just staying the same size while the environment around them is "growing". I'd love to have the options to *always* keep the bar in the same relative position to the mob, even if the bars have to overlap one another, and also have them scale with camera distance.
alas, all Aloft does is take over the underlying Blizzard bar-style nameplates and "tweak" them (in terms of texture/color, placement of visible elements relative to the underlying Blizzard nameplate anchor point, adding additional features in the form of mana/threat bars, text, etc).
all these idiosynchrasies of bar-style nameplate placement have their roots in that underlying Blizzard implementation.
and there is no "Nameplate API"... nameplates are just graphical elements created/destroyed/placed by the WoW client that Aloft has to extract from among the children of Blizzard's "WorldFrame" (essentially a big list of all currently active graphical elements). the nameplates themselves are in turn comprised purely of graphical elements (each nameplate is a pile of objects of type Frame/Texture/FontString hooked together in a particular way... raw Blizzard API stuff), and they have to be managed as such. Aloft even has to reverse-engineer which global graphical elements are nameplates by verifying the name of the texture used in a particular place on each nameplate (i.e. verify that the element is there, and then verify that the name of the associated texture is the expected one).
i have one word for all of this: bleah.
but i have always done best click-targeting off of nameplates (it has always been, for me personally, the quickest/easiest and most accurate way to manage the target process for myself). so, Aloft has always been a must-have for me... make those nameplates big and colorful, spread the associated text out where i can see it easily, and etc.
anyway, i am not certain how i would go about replacing nameplates completely, or even just managing those underlying anchor points in any meaningful way... in order to control placement on the screen relative to visible character models, and do it dynamically at runtime in a responsive way, etc.
If I recall correctly, doesn't adjusting the packing height/width affect how close the nameplates can be to each other? Haven't yet messed with the new versions, but seem to recall that in pre-wow 3.0.x versions.
packing height/width would make sense... but i have not noticed that it helps.
i will play with this some in a crowded place (like in front of the bank in Orgrimmar :)) and see if i can verify whether it helps.
maybe it's just from not having things work for me for so long, but are the nameplates positioning differently these days? i mean, now it seems that the nameplates don't seem to correlate to their units very well when there are many units on screen... i don't remember that issue before.
yeah, such as with those large Blood Elf trash mobs just up the first stairs in Karazhan. enough targets that the nameplates have to be tiled all over the screen without correlation to the unit's actual location, and the slightest motion on the part of any unit continuously/violently alters the tiling. a nameplate-targeting nightmare.
one thing that helps me in those situations is just disabling friendly nameplates, leading up to a fight. the fewer the visible nameplates, the less trouble the WoW client has making them all fit.
i have also experimented with trying to make the healthbar and other graphics more compact. it doesn't seem to help... seems like there is an invisible "footprint" on the screen for each nameplate (if the nameplate is enabled at all), and that "footprint" is somehow invariant.
i will put this on my list as a research project. maybe there are some frame/texture inset parameters (or something similarly obscure) i can alter that would affect this.
After a long long time away from the game, I logged in to the game today and checked on what's happening with Aloft (and other mods) that I wrote a while ago.
Just wanted to say thankyou to acapela for keeping the project alive.
And for the questions above; the WoWInterface download does have mobhealth references, but it doesn't require it, nor does it end up using it since the original Aloft code relating to health 'just works' :)
i would be happy to coordinate/collaborate with Roartindon in any way that Roartindon considered acceptable. we can discuss this here in this thread, or in PM here at WoWAce, whatever works best.
and... the only real reason Aloft moved at all was that i could not get any sort of commit access to the WoWAce repostory at the time, and the reason it moved to WoWInterface instead of Curse was WoWInterface's stability and ease of use at the time.
Curse seems to be improving now, though, so if some sort of page update/file upload permissions could be enabled for me (Curse user name "acapela") on Curse, and/or here at WoWAce (WoWAce user name "acapela"), i could maintain "my" version of Aloft at those places too. or, a merge of the codebases could be arbitrated in some fashion. whatever seems best to folks.
i could just create a new Curse page for it, but i have always felt forking Aloft to numerous places without knowing anything concrete about Roartindon's status, future plans, and etc would be counterproductive. and as far as i know, WoWInterface has no formal relationship with Curse (unlike WoWAce), which i felt reduced the potential for a "too many cooks" syndrome even further.
Roartindon is exactly correct, all the MobHealth/LibMobHealth/MobInfo2 references in Aloft are now useless/unhelpful (uploaded a new version just a day ago or so that took all of that stuff out). also the Threat-2.0 references are obsolete.these "auxilliary library" fixes were very quick/easy.
most of the time spent on the most recent release was spent instrumenting an Aloft-compatible "aggro glow" capability. Blizzard's textures and placement were so closely tailored to the default Blizzard nameplates that i could not figure out a way to re-use any of it (though i am learning more all the time about the WoW API and its intricacies, so i might fiddle with this again at some point soon; if it is feasible, re-use of at least the existing texture region would certainly be more efficient than the "OnUpdate" mirroring i am doing now).
i lost track of this thread in the WoWAce site refactoring. now that i have found it again, i will start watching it, and update the project description at WoWInterface to reference it. i can at least start announcing new WoWInterface releases here for those folks who find it convenient.
for those interested in "color tags" (specifically the magic text strings you would put into the "Color Format" text entry boxes in the "Aloft>Health Bar>Colors>Advanced" or "Aloft>Frame>Background Colors>Advanced" option dialogs), i rummaged the code and experimented.
here is an example:
this says: "all friendly paladins should be of color f48cba”, where color is of the form "rrggbb", each 2 characters representing a single channel of the color. this example happens to be the authentic Blizzard(tm) class raid color for paladins. the health bar "Advanced" option covers the health bar, and the frame "Advanced" option appears to cover the health bar background.
the magic string at the end representing the actual color must be 6 characters (alpha channel is ignored), hex, and should be in quotes (though occasionally you can get away without quotes, dunno why), but may be any mix of upper/lower.
any tag string that resolves, with conditionals, to a 6-character *literal* will be interpreted as a hex color when originating from these option fields. only the first 6 characters count. normal color tags like "HealthBarColor" don't apply in these "Advanced" color tags. there appear to be limits on total aggregate tag source text length, but i have not tried to quantify this. you would have room to tweak a few class colors, certainly.
i have enhanced the Aloft documentation (AloftTag.rtf, distributed with the addon) with a description of this specification. this will be checked in and bundled with the next release.
Check acapela's page for Aloft on WoWInterface; it's being updated there for WotLK, since he/she does not have SVN access here.
i have poked around and found i have read access to the WoWAce SVN (though i am leaving it at read access... i was never "officially" able to obtain commit access, in fact never had a word from the WoWAce folks of any kind, and i don't want to mess with things without permission, so i moved my fork of Aloft to WoWInterface).
having said this, i see a WoWAce version of Aloft currently being ported to WotLK in the SVN, under:
i have not yet tried to contact the WoWAce user (if they exist) who appears to be doing this work. i have not even tried running this version of Aloft. that person does not seem to have shouted out in this thread, but the change logs there suggest that they are doing the obvious things: embedding a WotLK-compatible Ace2, updating to LibSharedMedia-3.0, LibBabble-*-3.0, etc. i have also done these things.
"my" version of Aloft is already up and running on the PTR (WoW 3.0.2), and should be WotLK-ready, within reason. this is currently at (direct link):
i will do my best, at some point, to diff this WoWAce version of Aloft against its predecessors and make certain that there are no functional improvements i should incorporate (i have seen none to date, though it has been a few days). next on the list for me is incorporating Ace3, which should make things a bit more stable than cramming a succession of Ace2 development versions into Aloft :-). if i can ever get in touch with the WoWAce folks, i would also be happy to push my version up to the SVN here, at some point.
- 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.
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.
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, 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).
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).