Go to Page... |
Compatibility: | Minor patch (6.2.3) Fury of Hellfire (6.2) The Adventure Continues (6.1) Warlords of Draenor (6.0.3) Warlords of Draenor Pre-Patch (6.0.2) |
Updated: | 09-02-15 04:47 AM |
Created: | unknown |
Downloads: | 572,690 |
Favorites: | 977 |
MD5: | |
Categories: | Beta-version AddOns, Buff, Debuff, Spell, Casting Bars, Cooldowns, Combat Mods, Unit Mods |
This page is best viewed using the WoWI "default" or "dark" theme. Apologies for any inconvenience.
-----
The following is adapted from the original project description. Disclaimers at the bottom.
-----
This is a BETA release. Seeking assistance with any/all localizations (deDE, esES, frFR, koKR, ruRU, zhCN, zhTW, any/all others).
-----
Aloft is an addon that allows you to customize and enchance how nameplates and nameplate casting bars appear in the game.
-----
As of 2014/11/03, I will be on extended hiatus, possibly never to return. If you wish to take over maintenance of Aloft, please contact me via PM.
-----
The Aloft FAQ is HERE, please review it. (And please feel free to request additional information/clarification.)
NOTE: Keeping track of which versions of WoW are live on which non-North American realms is difficult; please PM me if you end up with an incompatible version, we can probably find something that will work for you.
NOTE: The current production release is Aloft-6.0.1 (Ace3), for WoW 6.0.2+ (Warlords of Draenor, at least prepatched on North American live realms as of 2014/10/14; not compatible with earlier versions of WoW). Aloft-5.2.8 (Ace3) is still available for WoW 5.X. Aloft-4.4.8 (Ace3) is still available for WoW 4.X. Aloft 2.8.3 (Ace2) or later is required for WoW 3.2. Some older versions may or may not still be available; send a PM to Acapela for older versions, and include your email address.
Quick answers to current "problems" (see recent Change Log entries for additional details):
-------------------------
Recent Changes (Aloft 6.0.1):
- fix for cast bar color/border/etc problem
- updated LibBabble-Faction-3.0 to latest/greatest (6.0-release2)
- updated Ace3 to latest/greatest (r1123)
Recent Changes (Aloft 6.0.0):
- ready for WoW 6.X; thanks to everyone who helped test the alpha
- updated TOC to 60000
- fixed spell ID issues in totem and crowd control modules
- fixed cast bar LUA error and configuration mode update issues
- fixed "recently damaged" option in AloftGlow module
- attempt at a fix for flickering duplicate unit name text
- updated Ace3 to latest/greatest (r1118)
Recent Changes (Aloft 5.2.8):
- disabled keybindings during combat
- disabled all combat-related auto-show/hide and auto-motion functionality
- updated Ace3 to latest/greatest (Release-r1109)
Recent Changes (Aloft 5.2.7c):
- fixed a small bug in cast bar cast activity handling
- updated Ace3 to latest/greatest (r1105)
Recent Changes (Aloft 5.2.7b):
- fixed a small bug in cast bar spell icon handling
Recent Changes (Aloft 5.2.7):
- updated Aloft to detect and propagate healthbar "tapped color" of 0x888888 (136/136/136); active on units tapped by others
- updated Aloft to show "default" cast bars on all nameplates (not just target); cast bar functionality is disabled if cast warning functionality is enabled
- made state icon size range larger
- updated Ace3 to latest/greatest (Release-1104)
Recent Changes (Aloft 5.2.6):
- fixed issues with cross realm character "Names (*)", now parsing correctly; be ready for potential issues with duplicate names
- added [IsCross] boolean text tag, for those who want to incorporate some indication of cross-realm in their text/colors
- updated LibBabble-Faction-3.0 to latest/greatest (5.4-release1)
- updated Ace3 to latest/greatest (Release-r1098)
Recent Changes (Aloft 5.2.5):
- updated TOC to 50400
Recent Changes (Aloft 5.2.4):
- updated TOC to 50300
- added scenarios to instance types for auto-show functionality
- all experiments to fix "state icon" alignment on nameplate show failed; replaced "state icon" completely
- updated LibBabble-Faction-3.0 to latest/greatest (5.3-release1)
- updated LibGratuity-3.0 to latest/greatest (r47 apparently just a TOC change)
- updated Ace3 to latest/greatest (r1086; apparently just a TOC change)
Recent Changes (Aloft 5.2.3):
- forgot to add Arena ID module icon background textures to repository! now added...
- applied various small fixes to avoid using Region:Show()/Hide() on sub-elements of the Blizzard nameplate frame assembly, to improve compatibility with "Healers Have to Die"
---
!!Tag Error!! Problems? Aloft options have disappeared? Aloft Presets not available or not loading properly?
A lot of Aloft functionality is now "dynamic" (not loaded by default). Enable this dynamic Aloft functionality via Aloft's "Modules" options. (See the screen shot of Aloft's options on the WoWInterface page for Aloft.)
!!Tag Error!! Issues: If you have "!!Tag Error!!" problems, either enable modules carefully one at a time until the problem(s) goes away, or (especially for custom text tag configurations) look at the document "AloftTags.rtf" (bundled with Aloft, in .../Interface/AddOns/Aloft/AloftTags.rtf), which details which text tags are supplied by which modules. A more detailed procedure is provided below.
Missing Options: If a module is not enabled, its options will not be present (as if the module was physically absent). If options seem to be missing in Aloft's waterfall, check to see if the associated module is enabled in Aloft's "Modules" options. Enable the module, and its options should appear "on the spot". (Only the AloftLDB module is loaded by default, to save memory.)
Presets: Aloft "dynamic" modules must be enabled before presets can be applied to them, and the "AloftPresets" module itself must be enabled before presets can be used at all. (the AloftPresets module is disabled by default to save memory.) A more detailed procedure is provided below.
!!Tag Error!! procedure, with nameplates displayed/visible:
Presets procedure:
To "goose" Aloft, try to Force Rebuilding of Text Tags, with nameplates displayed/visible:
Rinse/Repeat any/all of the above, as needed, to arrive at the desired configuration.
-------------------------
Options:
"/aloft"
"/aloft gui"
Direct support for FuBar (here and here) and LibDataBroker-1.1 are incorporated.
Under WoW 3.0.2 and later, Aloft no longer requires (nor can it even benefit from) external libraries for health estimation (i.e. MobHealth3, LibMobHealth-4.0, MobInfo2) or threat (i.e. Threat-2.0)
-----
The customization options in Aloft allow you to change the size, shape, anchors, font, font options, textures and colors of:
1. Name text
2. Level Text
3. Health Bar
4. Mana Bar
5. Cast Bar
6. Spell Icon
7. Boss Icon
8. Raid Icon
9. Mouseover Highlight
Aloft also enhances the display by providing options for:
1. Health text - you can display health percentage, health, or health deficit right on the nameplate
2. Spell name - Aloft will place the spell name right on the casting bar
3. Spell casting timer - Displays the remaining casting time
4. Combo Points/Lacerate/Sunder text - Displayed on current target's nameplate for druids (while in the relevant form), rogues, and warriors
5. Recently Damaged icon - Displays an icon next to any unit that has recently taken damage
6. Finer visibility control - A collection of options that give you specific control over which nameplates are shown - eg. You can hide friendly pets, out-of-guild players, and lots more
7. Guild Text - Show guild information right on the nameplate. Shows abbreviated forms by default.
8. Border and backdrop color
9. Comments - Show "Banker", "Flight Master" and other automatically gathered comments, or your own custom ones right on the nameplate
10. Mana Bar/Text - show group member/pet/summon mana, energy, rage
11. Combat Text - display all damage and healing done to group members or targets right on the plate.
12. Pets Owner's Names
13. Polymorph Timer/Shackle Undead/Banish Timer bars
14. Unit Aliases
15. Class Icons
16. Player Titles (PvP, Reputation, and Achievement titles, segregated by prefix or suffix)
17. Experimental: Target-of-target subsystem; see FAQ
18. Keybindings for toggling enemy nameplates, friendly nameplates, and all nameplates
19. Integrated with SharedMedia (for extra fonts and textures: SharedMedia)
Finally, Aloft (this UPDATED version) provides a full-featured threat indicator capability:
1. Player threat displayed on player target's nameplate (the player has no bar-style nameplate)
2. Group threat (including pets/summons) displayed on group nameplates; see FAQ
3. Threat bar and threat text capabilities
4. Threat bar and threat text can be enabled independently
5. Can be enabled while solo (for pet-owning classes)
6. Control over display colors to indicate common threat and maximum threat thresholds
7. Threat gain threshold display (i.e. omen-style "aggro bar") capability for player threat
8. Threat threshold nameplate "glow" (separate from aggro glow, see below); Threshold can be customized
9. Experiemntal: AOE threat subsystem; threat displayed on hostile nameplates for units other than the player's current/active/primary target; see FAQ
As well, on a related note, Aloft provides:
10. Aggro namplate "glow" (for AOE tanking/etc), replacing the Blizzard native aggro "glow"; Note that aggro glow is completely separate from threat system
NOTE: Aggro nameplate "glow" will only be displayed if the underlying Blizzard "Display->Display Aggro Warning" is enabled for the state you are in (i.e. Always/Party/Instance, etc)
-----
Other threat addons (thanks to their authors for unknowningly providing example code for Aloft's current threat implementation):
Omen3: Omen
IceHUD_Threat (now obsolete; primary target threat is a direct feature of IceHUD): IceHUD, IceHUD_Threat
ZThreatMeter (now apparently obsolete): ZThreatMeter
-----
All of the additional options are written to require no additional overhead if they're not enabled (though they will occupy memory when Aloft is loaded).
Aloft is designed to be easily extensible. All of the functionality is separated into discrete modules which should make it relatively easy for people to tinker with adding their own functionality.
If you want additional texture options, make sure you install SharedMedia. For additional font options, ClearFont2 and its fontpacks provide a number of extra font choices.
Documentation for the text tag format is included with the addon (look at the file AloftTag.rtf). Please also look at CREDITS.txt and CHANGELOG.txt for a history of the project.
Aloft is still (again?) a work in progress. Defect reports, feature requests, and code reviews are welcome.
On behalf of all the original contributors, Acapela hopes you enjoy it.
-----
DISCLAIMER: Acapela is not the original author of this addon. Please refer to README.txt, CREDITS.txt, and CHANGELOG_WOWACE.txt for more information on the history of Aloft.
Aloft has been updated. It would be branded a "fan update" except the original author(s) have long since vanished, and Aloft is in fact being actively maintained, for the forseable future, by Acapela.
Acapela intends to host the addon here at WoWInterface (SVN and distribution).
NOTE: The addon is not maintained by Acapela at either of WoWAce or CurseForge (though earlier/"original" versions are still available there).
The WoWAce revision on which this version is based is r80814 (http://www.wowace.com/projects/aloft/; this is WAY out of date, now a WoWAce "obsolete" project; the WoWAce version was not transferred to Curse).
Please report all errors as they are discovered (either in the comments for Aloft here on WoWInterface, or via the WoWInterface bug report mechanism), and Acapela will attempt to resolve them and apply a fix.
Acapela will participate in the forum thread for Aloft at WoWInterface (http://www.wowinterface.com/forums/s...ad.php?t=18093), as well as the commentary associated with the page for the addon itself at WoWInterface.
Acapela will continue to participate in the the original official forum thread at WoWAce (http://forums.wowace.com/showthread.php?t=5437).
A private message to "acapela" at WoWInterface will also reach him.
Acapela does not want Aloft to die, so Acapela will make every effort to find someone to take over should he find himself unable to continue with this commitment. If anyone would be interested in participating in development, please contact Acapela.
NOTE: Current users of Aloft should backup/delete their .../Interface/Addons/Aloft folder before installing this version of Aloft.
It would also probably be a good idea, to avoid problems, to backup/delete your .../WTF/Account/<WoWUsername>/SavedVariables/Aloft.lua file as well.
----------
As always, Aloft is free with your materials, but if you want to donate:
Comment Options |
Koviko |
View Public Profile |
Send a private message to Koviko |
Find More Posts by Koviko |
Add Koviko to Your Buddy List |
12-09-12, 11:10 PM | |||
|
Aloft characterizes units into coarse "types" based on nameplate health bar color (green means friendly NPC, blue means friendly PC, class color means hostile PC, etc). these types roughly correspond to the breakdown used in the Visibility module, to show/hide specific variations of unit (as well as the breakdown in HealthBar and Frame background, for custom colors). since Blizzard has introduced this new nameplate health bar color for "tagged" units, the ability to determine basic unit type based on nameplate health bar color is presumably lost for these tagged units (though i doubt this "tagged" color would be used on PCs, for instance, so it may be possible to infer at least "hostile NPC" from the use of the tagged color; more enhancements/refinements will be added if they are discovered). so, i have enhanced Aloft accordingly, to add a "tagged" unit type (including detecting color change during combat and updating everything accordingly), and am testing. this should at least result in consistent treatment of tagged units (and it definitely does NOT confuse tagged mobs with hostile players, etc). i will look into providing [TaggedColor] tags, as well (per Thortok2000). i will also go look at the mobs mentioned by kovik.
__________________
Retired author/maintainer of Aloft (the nameplate addon) http://www.wowinterface.com/download...AloftBeta.html ----- Zippy said it best: "All life is a BLUR of Republicans and Meat!"
Last edited by acapela : 12-12-12 at 09:58 AM.
|
||
|
acapela |
View Public Profile |
Send a private message to acapela |
Find More Posts by acapela |
Add acapela to Your Buddy List |
12-12-12, 10:22 AM | |
|
Release: Aloft-5.1.2-2461
a new release of Aloft is available, pending moderator approval: Aloft-5.1.2-2461.
primarily, this has changes to enable "tapped" units, indicated by nameplate health bar color. this has had some testing, but please report any problems.
__________________
Retired author/maintainer of Aloft (the nameplate addon) http://www.wowinterface.com/download...AloftBeta.html ----- Zippy said it best: "All life is a BLUR of Republicans and Meat!" |
|
acapela |
View Public Profile |
Send a private message to acapela |
Find More Posts by acapela |
Add acapela to Your Buddy List |
12-12-12, 11:38 AM | |
|
I guess you put a lot of effort into this project. Thanks
|
|
Deadlyz |
View Public Profile |
Send a private message to Deadlyz |
Find More Posts by Deadlyz |
Add Deadlyz to Your Buddy List |
12-12-12, 01:27 PM | |
|
Unable to determine module providing data: isTapped
This doesn't work: [~IsPlayer:IsTapped:Name] I also can't find a 'TappedColor' to assign to it. Ultimately the final tag I would like to have is this: [~IsPlayer:IsTapped:Name:TappedColor][~IsPlayer:~IsTapped:Name:NPCRepColor][IsPlayer:~IsFriendly:"(((":Red][PlayerTitlePrefix:Suffix(" "):HealthBarColor][IsPlayer:Name:HealthBarColor][PlayerTitleSuffixSeparated(", "," "):HealthBarColor][IsPlayer:~IsFriendly:")))":Red] NPCRepColor, if I remember correctly, reverts to 'OriginalHealthBarColor' (or it could be 'HealthBarColor', I forget) when it is not altering the color based on rep (for those with rep unknown or no rep). It would be good if 'OriginalHealthBarColor' would return the tagged color when the mob is tagged. It would be even better if mobs with the same name could have different colors if the original healthbar is colored differently. Try dueling some "Student of Chi-Ji", they always turn green and run away when you kill them. You can easily test the tagged setting anywhere there's dailies, there's always someone there killing stuff. If you use the default healthbars, each healthbar is correctly colored based on THAT UNIT's response, not on the response of the last unit of that name that you mouseovered. This is one core functionality of default healthbars that Aloft doesn't replicate and I would really like it to. It's not too vital for hostile/friendly switching but it is of course very vital to tagged/not tagged switching. A healthbar may be on screen as hostile and then without leaving the screen it becomes tagged, but all the other healthbars near it of the same name haven't become tagged. It's important to know which ones are tagged and which ones aren't. Also, I don't get into the whole 'tagged by player' 'tagged by all' thing. Either it's got a tagged color healthbar or it doesn't. Certain quest mobs are what I call 'quest taggable' meaning as long as you hit it once you get credit when it dies. Using the default healthbars, these stay red even when in combat with others. Most mobs, however, turn the 'tag' grey color as soon as someone tags them. I want Aloft to mimic this as well...to not be 'tagged' until/unless the HEALTHBAR is tagged color. Using the built in API for detecting tagging doesn't seem exactly the same. I didn't think about a visibility option but that's cool. What I would like instead is a way to shade the alpha if it's tagged. I don't want it completely hidden, but fading them out and turning their name Grey (or whatever the tagged color is) would be really useful.
__________________
“I don’t know half of you half as well as I should like; and I like less than half of you half as well as you deserve.” — Bilbo Baggins, from his speech on his eleventy-first birthday. |
|
Thortok2000 |
View Public Profile |
Send a private message to Thortok2000 |
Find More Posts by Thortok2000 |
Add Thortok2000 to Your Buddy List |
12-12-12, 06:00 PM | ||
|
as for the rest... understand that ***Blizzard*** throws up a "tapped color" on nameplates (in Aloft terms, this would be an "[OriginalHealthBarColor]" change), for units that are tapped in such a way that the player will not have access to rep/exp/loot/etc. Aloft detects and mirrors that color switch. the additional [IsTapped] flags i am trying to implement are there only for the player's current target, as a means of allowing the player to differentiate more fully. again, that Blizzard-applied "tapped" color obfuscates all other nameplate colors (class color, red vs green vs blue, etc), and consequently every other piece of information that could be derived from that color. finally, while i am not 100% sure that this "tapped" color ever shows on anything but NPCs (can PvP player targets be "tapped", for HK purposes or whatever?), regardless, i have definitely seen it on NPCs that originally started out as "hostile", as well as NPCs that originally started out as "neutral". so recovering original red vs yellow colors would be impossible, short of "remembering" original (non-tapped) colors based on unit name or something. same for class colors on PvP targets (or even differentiating players from NPCs to begin with). details: there are very few things actually attached to nameplates that Aloft can rely on as identifying information: health bar color (red/green/blue/yellow/class color, "[OrignalHealthBarColor]"... now including Blizzard's "tapped" color), unit name (and some assumptions about the uniqueness of unit name based on health bar color), raid target icon (if showing, this allows absolute ID for grouped players), boss icon (not reliable, it can sometimes reflect just unit level differential), and to some extent unit level (also not reliable). additionally, Aloft can always identify the target nameplate (if visible) via nameplate alpha. once a nameplate is positively identified (via whatever means), Aloft can stick additional information (obtained from mouseover or target action) on the nameplate that the player can use. this information will remain valid only as long as the nameplate remains visible. otherwise, it has to be "remembered" or re-acquired. for transient information (that can vary from second to second, like "tapped", as opposed to something like player class), i can't think of a reliable approach other that actual target switching. i need to read over the rest of your feature request, but i am guessing most/all of it will not be possible. having said that, i may be able to add a tag that provides easy/compact boolean access to whether the "[OriginalHealthBarColor]" matches a certain hex value (if such a tag doesn't already exist), which would allow conditional addition of text of a particular color, even for non-target nameplates. i expect modifying just the alpha channel of an existing color will not be possible (in the context of something like a text tag), but i haven't had time to think about it. modifying the alpha of the whole nameplate would also be problematic from a text tag. you can already control the basic appearance (health bar color, frame background color, and visibility) of a nameplate that has an "[OriginalHealthBarColor]" matching Blizzard's "tapped" color. i can modify to allow control of alpha for the health bar and frame background colors, if you want (probably already available the frame background color).
__________________
Retired author/maintainer of Aloft (the nameplate addon) http://www.wowinterface.com/download...AloftBeta.html ----- Zippy said it best: "All life is a BLUR of Republicans and Meat!"
Last edited by acapela : 12-12-12 at 06:03 PM.
|
|
|
acapela |
View Public Profile |
Send a private message to acapela |
Find More Posts by acapela |
Add acapela to Your Buddy List |
12-13-12, 10:40 AM | |
|
You're losing me, let's start over from the beginning. Here's a rough algorithm of what I can see being possible within the limitations of the game's API.
(One more correction, I have seen friendly npc's become tapped (by the enemy faction of course) while doing dailies in the new Shieldwall dailies area. I do not think players can become tapped, I haven't seen it happen. Keep in mind that when it comes to an HK, a player can't be 'tapped', everyone who hits that player gets some honor whether they are in a group or not.) - When a unit is not tapped (detected by the healthbar color being anything but tapped color), 'record' data, recorded under the name of that unit, about whether it is hostile/neutral/friendly. Return false for 'IsTapped' - If a unit is tapped (detected by the healthbar color being the tapped color), return true for 'IsTapped' and block all data recording for that unit via that healthbar. However, data recording from target and mouseover should still work (I believe the game does have 'ishostile' checks for target and mouseover.) --This means that if a unit has never been seen before and is not in the database and the first time you see it, it's tapped, there needs to be a 'default' to return to. (Much like the 'unknown' color for class color when class is not yet known.) For color, I suggest the tagged color as a default 'unknown' color for npc's. However, you also need to decide how 'unknown' will return for tags like IsHostile, IsFriendly, IsNeutral. You can assume any tagged mob is an NPC, so you can return false for IsPlayer just fine. ---The easiest way to do this in my opinion is to allow the user to set in the GUI what to 'assume' a tagged mob with no data is. Remember this lasts only until you target (or possibly mouseover as well) the tagged mob with unknown data, but there needs to be a default backup to last until that happens so that the healthbar can display SOMETHING. So again, user can choose how healthbars should 'behave' if data is unknown, and the user can select to default to 'hostile', default to 'neutral', or default to 'friendly.' The default default if user doesn't set anything would be 'hostile.' ---The other option is you can provide a 'isDataUnknown' tag of some sort so the user can customize what it should look like in a more advanced way. (Or you could do both.) - Finally, make the color of a healthbar displayed by Aloft potentially independent of the data in regard to its name. If the user is using 'originalhealthbarcolor' or 'healthbarcolor' then the bar should immediately change color to reflect the color change by the default non-aloft healthbars whenever the color of the non-aloft healthbars changes. If this color changes to 'tagged' it should immediately return true for 'IsTagged' for that healthbar only, not for any other healthbars on the screen with the same name. -- For healthbars that change back and forth between hostile and friendly (and other colors), I suggest that similar to the tagged color, that you block all data recording for hostile/friendly when in combat, IF you already have data for that name. But still make sure that any healthbars displayed on screen are displaying independently of that data, based on the in-game color displayed. And finally, return data for ishostile/isfriendly independent of the name, for each healthbar. So if 'guard' over here is friendly and 'guard' over there is hostile, the first guard is displayed as a friendly npc (and all the isfriendly tags are true) and the second guard is displayed as hostile (and all the ishostile tags are true). As far as the data permanently stored for the name 'guard', that's based on the last target or mouseover before you entered combat. -- As long as you set the color of the healthbar to have the power to 'override' the data stored for that name, independently, so that mobs with the same name can have different color healthbars (just like the default non-aloft healthbars work), the only time you would ever need to 'store' data regarding ishostile or isfriendly for the name of a mob is for tagged mobs. -- With that in mind, there's one final method you could use, possibly the easiest of them all. Consider friendly/neutral/hostile/tagged to be four separate data categories. IsFriendly,IsNeutral,IsHostile,IsTagged. Only one of these can return true at any time, at which point all the others return false. This would mean that a Tagged mob, for the purposes of aloft and customization, is not friendly, neutral, or hostile, it's tagged. What you could do instead is 'IsHelp' or 'IsHarm' (similar to how the [help] and [harm] work in macros), and that data you can get from target. So if your target is tagged, you can designate it as 'help' or 'harm' using the tags. This would only apply to the tagged category and only apply to the target, not any other tagged mobs (this would be the game's limitation of course, and not aloft's fault). Any tagged mobs not the target would return false for both 'help' and 'harm'. If you use the method outlined in this paragraph you can basically stop recording per-name friendly/neutral/hostile data altogether and have it all based on the color of the healthbar displayed on screen. ~ Hopefully that isn't too much to throw at you. To review, there's basically two methods you can take. Keep everything working like it is now, recording data per name, ignoring data when the mob is tagged, and very importantly allowing the default color of the healthbar to 'override' the data associated with the name of the mob on an individual per-nameplate basis. A way of handling the data for friendly/neutral/hostile when the mob is tagged and there's no data for that mob's name has to be determined. Or, the option I think which is more simple, which is to not handle that at all and just return false for friendly/neutral/hostile and return true for 'tagged' and the user has to set up what they want to display when that happens. You can, however, detect 'harm' or 'help' for your target, even on tagged mobs. Since aloft can determine which healthbar is the target (even among a crowd of healthbars all with the same name and color), you can make 'harm' and 'help' tags that only work on the target. (There may be a way to get this data from mouseover if you can tell the color of the healthbar that you're mousing over, and associate the harm/help tag with a combination of name+color. Associating harm/help with name would result in occasional bad data.)
__________________
“I don’t know half of you half as well as I should like; and I like less than half of you half as well as you deserve.” — Bilbo Baggins, from his speech on his eleventy-first birthday.
Last edited by Thortok2000 : 12-13-12 at 11:21 AM.
|
|
Thortok2000 |
View Public Profile |
Send a private message to Thortok2000 |
Find More Posts by Thortok2000 |
Add Thortok2000 to Your Buddy List |
12-13-12, 10:44 AM | |
|
I'm putting this in a separate comment since they're less complicated suggestions and I don't want to detract from everything I said in the other comment. There's two more suggestions for features I'd like to see that are much simpler.
- A 'TaggedColor' to use when the mob is tagged. Or maybe I just need to fix NPCRepColor to mimic whatever changes you've made to OriginalHealthBarColor. - A way to adjust visibility options with alpha instead of completely hide/don't hide. Most I would want to hide completely, like usual, but there may be some that I would rather have at like 10% alpha, almost invisible but not completely. This would hopefully be on a per-option setting instead of an 'everything' setting. I might want pets more visible than totems, etc.
__________________
“I don’t know half of you half as well as I should like; and I like less than half of you half as well as you deserve.” — Bilbo Baggins, from his speech on his eleventy-first birthday. |
|
Thortok2000 |
View Public Profile |
Send a private message to Thortok2000 |
Find More Posts by Thortok2000 |
Add Thortok2000 to Your Buddy List |
12-13-12, 04:09 PM | |||
|
summary: the ability to concretely identify a visible nameplate, as a UI object, is very limited under almost all circumstances. but in order to associate gathered information with a nameplate, i need that concrete identification. to have concrete idendification, i basically need (at least) one of three scenarios:
so while gathering most/all of what you suggest is possible, actually getting the information onto the nameplate for tag use could be tricky. Aloft already gathers pretty much all of the gatherable data, like "classification" (beast, humanoid, etc), "race", and so on. Aloft doesn't currently track whether something it has seen before was verifiably friendly, neutral, or hostile, but that could be added. there might be some utility in some of your suggestions, allowing Aloft's knowledge of such data, it's presence in Aloft's "database", to "override" the "tapped" color under certain circumstances. i am not certain that will be reliable enough to be useful. i will give it some thought, try to break down the cases.
your suggestion of changing the sense of the "[IsTapped]" tag, as Aloft currently provides it, is probably a good one: i should derive "[IsTapped]" purely from the "OriginalHealthBarColor", put it on all affected nameplates, and provide a different tag to reflect the value of the Blizzard UnitIsTapped() API function, for the player's current target. i will implement this much to start with, and then cogitate on all your other suggestions (including your proposed "[IsHelp]"/"[IsHarm]", and/or "[IsFriendly]"/"[IsHostile]"/etc).
__________________
Retired author/maintainer of Aloft (the nameplate addon) http://www.wowinterface.com/download...AloftBeta.html ----- Zippy said it best: "All life is a BLUR of Republicans and Meat!" |
||
|
acapela |
View Public Profile |
Send a private message to acapela |
Find More Posts by acapela |
Add acapela to Your Buddy List |
12-13-12, 04:38 PM | |
|
Before I say anything further, I'm going to dip into NPCRep module and see what's going on there and how much you've already fixed.
__________________
“I don’t know half of you half as well as I should like; and I like less than half of you half as well as you deserve.” — Bilbo Baggins, from his speech on his eleventy-first birthday. |
|
Thortok2000 |
View Public Profile |
Send a private message to Thortok2000 |
Find More Posts by Thortok2000 |
Add Thortok2000 to Your Buddy List |
12-13-12, 05:25 PM | |
A Deviate Faerie Dragon
Forum posts: 15
File comments: 32
Uploads: 0
|
I've never seen an addon developer so friendly and open to suggestion before. I have so much respect for you right now.
|
|
Koviko |
View Public Profile |
Send a private message to Koviko |
Find More Posts by Koviko |
Add Koviko to Your Buddy List |
12-14-12, 02:06 AM | |
A Kobold Labourer
Forum posts: 0
File comments: 27
Uploads: 0
|
Everything works fine, although i have 2 minor problems.
- Highlight on mouseover ain't working no more, dunno since when, but it didn't 2 weeks ago and it still ain't working now, (yes i updated to the last version btw). - The casting bar is very glitchy, as in it looks like the casting bar fills up 3 or 4 pixels per time instead of having a linear growth, sort of looks like lagging in fps. Also, it shows 2 decimals, would like to know how to show only 1 decimals. Thanks for the great addon! EDIT I've scrolled pages and found an answer to the first point, although do you have plans to actually make it work? i know other addons still have options about this, like while mouseovering non targets their alpha would increase, or perhaps apply a border colour / glow
Last edited by madmatt91 : 12-14-12 at 02:24 AM.
|
|
madmatt91 |
View Public Profile |
Send a private message to madmatt91 |
Find More Posts by madmatt91 |
Add madmatt91 to Your Buddy List |
12-14-12, 10:04 AM | ||
|
Blizzard used to build a highlight-on-mouseover capability into their default nameplates, which Aloft just "reskinned". this feature went away under WoW 5.X (maybe it was more recently with WoW 5.1?). i have not had time yet to experiment to see if there is a workaround. there is definitely at least one thing i should try... but we may be out of luck. for a stuttering casting bar, try enabling the Cast Warning module, and then enable "Cast Warning>Override" and set "Cast Warning>Update Interval" to zero (0). see if that results in a smoother animation style.
__________________
Retired author/maintainer of Aloft (the nameplate addon) http://www.wowinterface.com/download...AloftBeta.html ----- Zippy said it best: "All life is a BLUR of Republicans and Meat!"
Last edited by acapela : 12-14-12 at 10:29 AM.
|
|
|
acapela |
View Public Profile |
Send a private message to acapela |
Find More Posts by acapela |
Add acapela to Your Buddy List |
12-14-12, 10:06 AM | ||
|
__________________
Retired author/maintainer of Aloft (the nameplate addon) http://www.wowinterface.com/download...AloftBeta.html ----- Zippy said it best: "All life is a BLUR of Republicans and Meat!"
Last edited by acapela : 12-14-12 at 10:09 AM.
|
|
|
acapela |
View Public Profile |
Send a private message to acapela |
Find More Posts by acapela |
Add acapela to Your Buddy List |
12-14-12, 12:26 PM | |
|
What I meant was, I did not want to attribute any flaws to Aloft that were actually flaws in NPCRepColor module.
For instance, now that I've done some testing with OriginalHealthBarColor instead of NPCRepColor, I see that hostile/friendly swaps seem to work perfectly. Tagged doesn't work yet, it throws this LUA error. I also haven't had a chance to test hostile/friendly when there's one of each on the screen at the same time. Once you finish up getting OriginalHealthBarColor working, I will get NPCRepColor working behind it. The tag I'm using for testing (and throws a LUA error when I encounter tagged mobs) is this: [~IsPlayer:Name:OriginalHealthBarColor][IsPlayer:~IsFriendly:"(((":Red][PlayerTitlePrefix:Suffix(" "):HealthBarColor][IsPlayer:Name:HealthBarColor][PlayerTitleSuffixSeparated(", "," "):HealthBarColor][IsPlayer:~IsFriendly:")))":Red] And here's the LUA error: Date: 2012-12-14 13:21:51 ID: 1 Error occured in: Global Count: 1 Message: ..\AddOns\Aloft\Aloft\AloftNameText.lua line 490: attempt to call field '?' (a nil value) Debug: Aloft\Aloft\AloftNameText.lua:490: ?() ...Ons\Ace3\CallbackHandler-1.0\CallbackHandler-1.0.lua:147: ...Ons\Ace3\CallbackHandler-1.0\CallbackHandler-1.0.lua:147 [string "safecall Dispatcher[2]"]:4: [string "safecall Dispatcher[2]"]:4 [C]: ? [string "safecall Dispatcher[2]"]:13: ?() ...Ons\Ace3\CallbackHandler-1.0\CallbackHandler-1.0.lua:92: SendMessage() Aloft\Aloft\AloftHealthBar.lua:550: SetHealthBarColors() Aloft\Aloft\AloftHealthBar.lua:527: SetHealthBarColor() Aloft\Aloft\AloftHealthBar.lua:659: ?() Aloft\Aloft\AloftHealthBar.lua:742: Update() Aloft\Aloft\AloftHealthBar.lua:499: ?() ...Ons\Ace3\CallbackHandler-1.0\CallbackHandler-1.0.lua:147: ...Ons\Ace3\CallbackHandler-1.0\CallbackHandler-1.0.lua:147 [string "safecall Dispatcher[2]"]:4: [string "safecall Dispatcher[2]"]:4 [C]: ? [string "safecall Dispatcher[2]"]:13: ?() ...Ons\Ace3\CallbackHandler-1.0\CallbackHandler-1.0.lua:92: SendMessage() Aloft\Aloft\Aloft.lua:276: ProcessHealthBarColorChange() Aloft\Aloft\Aloft.lua:609: Update() Aloft\Aloft\Aloft.lua:525: Aloft\Aloft\Aloft.lua:525 (tail call): ? [C]: ? [string "safecall Dispatcher[1]"]:9: [string "safecall Dispatcher[1]"]:5 (tail call): ? Ace3\AceTimer-3.0\AceTimer-3.0.lua:166: Ace3\AceTimer-3.0\AceTimer-3.0.lua:138 Locals: None
__________________
“I don’t know half of you half as well as I should like; and I like less than half of you half as well as you deserve.” — Bilbo Baggins, from his speech on his eleventy-first birthday. |
|
Thortok2000 |
View Public Profile |
Send a private message to Thortok2000 |
Find More Posts by Thortok2000 |
Add Thortok2000 to Your Buddy List |
You have just downloaded by the author . If you like this AddOn why not consider supporting the author? This author has set up a donation account. Donations ensure that authors can continue to develop useful tools for everyone.