can i get a quick update on the status/future of this mod?
i have used it since forever, it has continued to work with very rare little glitches through multiple WoW client patches, and i would like to keep using it. but, i have not seen an "update" for it for quite a while now, not even a 2.4.x TOC tweak.
so far, an update may not have been necessary, but... WotLK is looming, and i don't know if Aloft is going to be continued (i.e. will WotLK features subsume it and therefore render it superfluous, render it or anything like it technically infeasible, will it just keep humming along fine with a TOC tweak, or what?)
can i get a quick update on the status/future of this mod?
There haven't been any updates because the author has disappeared, and nobody else has volunteered to maintain the addon. The TOC hasn't been updated to indicate 2.4 compatibility because the addon isn't fully compatible with 2.4; it still references the now-defunct Threat-1.0, for example. I have no idea if Aloft will continue to mostly function in WotLK or not, although I suppose I'll find out soon once my beta client finishes downloading and installing.
Commit by ammo :: r79887 ClassColoredNameplates/ClassColoredNameplates.lua:
ClassColoredNameplates: only scan for nameplates when worldframe children change, cache plates
Which made me hope that maybe ammo was working on a replacement of some sort. The main thing I use this mod for is to color the nameplates by class (okay well and I changed their texture and removed their border, but I can live with them not being 'pretty')
There haven't been any updates because the author has disappeared, and nobody else has volunteered to maintain the addon.
alright, understood. i don't want to "officially" volunteer, but i like the addon quite a bit, don't really see anything like it out there, and of course there are a few issues with it, so i may start fiddling with it.
on the immediate agenda would be:
- updating the tag system to use LibDogtag-3.0 (whatever the latest/greatest state-of-the-art is), assuming this is technically feasible; i gather UnitIDs are not available from nameplates, so i will have to figure this out
- updating the threat subsystem to LibThreat-2.0; i assume the same issue exists here with UnitIDs
- fixing mouse interaction (which i notice is not working for me now), assuming this is not something blizzard has broken in the underlying nameplate subsystem
any other issues Aloft users have noticed, in the way of 2.4-compatibility or broken features, feel free to mention them in this thread. i could easily smack into dead ends on lots of stuff, but i will give it a look.
i am pretty bored with the game right now anyway, marking time pending WotLK, so this might be fun. and if i can wrangle together a 2.4-compatible version of this, it probably won't be a major effort to bring it forward into WotLK as well.
i suppose with the impending refactoring of WoWAce as a mod site, i should probably distribute anything i come up with somewhere else (WoWInterface would probably be my pick, too many mod authors seem to be loosing hair over at curse). suggestions on this would also be welcome.
thanks again for the info. i will follow up here as i can.
i am pretty darn familiar with frame changing addons and their options, yet i cannot get Aloft to display mana bars at all. I am trying to have both health and mana bars displayed to match my unit frames.
Since the question was brought up, I just wanted to note that according to this, Aloft has alreay been reported as nonfunctional in WotLK to some extent or another (no details listed there unfortunately).
- updating the tag system to use LibDogtag-3.0 (whatever the latest/greatest state-of-the-art is), assuming this is technically feasible; i gather UnitIDs are not available from nameplates, so i will have to figure this out
I would actually strongly prefer that Aloft did not use DogTag. TagCompiler is much simpler, and more importantly, does not consume more CPU cycles and increasing memory than most of my other ~150 addons combined, wheras DogTag does, even though the only addon I run which uses it is an action bar addon that uses DogTag to display key bindings (which almost never change) and item counts (which change rather infrequently in the grand scheme of things). If I could find another bar addon that covered most of what InfiniBar does, but didn't require DogTag, I would immediately dump InfiniBar.
- updating the threat subsystem to LibThreat-2.0; i assume the same issue exists here with UnitIDs
Correct, although with WotLK looming, I'm not sure it's worth the effort, as actual threat values will now be exposed through the WoW API and will not require Threat-x.0 to estimate them.
- fixing mouse interaction (which i notice is not working for me now), assuming this is not something blizzard has broken in the underlying nameplate subsystem
What do you mean? Mouse interaction works fine for me.
WoWInterface would probably be my pick
^ I'm already using WoWInterface as my primary addon host, and now that they've got SVN repos, I'm using them for my development as well. I'm still committing "release" versions here on WowAce for updater users, but I'll probably pull them shortly so I can see what the new site has to offer before uploading again.
I would actually strongly prefer that Aloft did not use DogTag.
good point. i may deprioritize this, or code it in such a way that the choice of tag system can be selected somehow. i was not aware DogTag was... a dog? i use it several places (or the authors of the mods i use use it several places; IceHUD, CowTip, etc), and i have been accustomed to doing things with it. it just seemed natural to bring Aloft into the fold. anyway, setting it up so that either could be used could permit some benchmarking, and that would probably be the only way for me to really clarify this to myself.
threat values will now be exposed through the WoW API and will not require Threat-x.0 to estimate them.
i will try to dig into the new WoW-organic threat API (and maybe i can compare current and beta versions of Omen, Diamond, KLH, and etc, assuming they exist). again, perhaps, it will be easy to do it one way for the next month or two and then swap over when WotLK actually arrives. i am still looking at how Aloft collects and maintains unit data for use in nameplates, there is an elaborate lifecycle there, of which threat is just a part...
What do you mean? Mouse interaction works fine for me.
for reasons unknown to me, while native WoW nameplates permit mouse left/right-click on them for selection and interaction... Aloft nameplate frames have gone dead for me, as far as the mouse is concerned. this is under all circumstances, without regard for whether i am in combat or whatever. it could be something i have configured somehow (though actually enabling mouse interaction in Aloft, as a specific option, has no effect on this behavior). it could be synergy with another mod. i just don't know at this point. i have been looking at how Aloft believes it controls nameplate frame mouse interaction, and i expect i will need to trace it diagnostically (print out messages as the state of mouse interaction is controlled), and understand what user interface behavior i obtain relative to what Aloft believes it is doing. that will hopefully help me visualize how this is going wonky for me.
I'm already using WoWInterface as my primary addon host, and now that they've got SVN repos, I'm using them for my development as well.
i figured that is what i would be doing, assuming i got that far. i have not tried to use any of the sites as a mod author, but i have read forum posts from authors describing general difficulty of use at curse, and lack of response getting projects approved at WoWAce, and the relative ease of use and comparatively responsive support at WoWInterface. i also use the WoWInterface automatic updater, and find it a nice feature. WoWInterface will probably be what i try first.
first i want to get deep enough into this that i can have some degree of confidence i will be adding value, before i try to set up a bunch of infrastructure.
thanks for the comments, everything like this is very helpful.
from WAAAAAAAAAAAAAAAAY earlier in this thread and from the author regarding dogtags:
DogTag is a tag compiler that produces and handles strings for unitids.
TagCompiler is a tag compiler that determines strings, raw values or numeric values for a generic set of data. It does not handle updating strings. I had to write this, because Aloft does not have unitids to work with, so cannot use DogTag.
I tried searching for a TagCompiler FAQ regarding the syntax and I have been unable to find anything. I want my nameplates show up to 15 characters - if the name is longer (Tyrande Whisperwind comes to mind), it would shorten the name to 13 characters and add three dots (would end up looking like this: "Tyrande Whisp..."
I tried searching for a TagCompiler FAQ regarding the syntax and I have been unable to find anything.
there is a TagCompiler RTF document, at least summarizing the syntax, distributed as part of Aloft. i have rummaged the Aloft code for various purposes over the past year or so, and have seen tags implemented that don't appear to be documented in this RTF document (like PetOwnersName), but the RTF does supply some examples and a summary of pretty much all the tags.
Aloft does not have unitids to work with, so cannot use DogTag
ahh yes. i suppose i had been thinking in terms of incrementally collecting unit GUIDs, as targets were moused over, selected, and etc (and their GUIDs could be constructed)... Aloft does a fair bit of this anyway, caching a variety of different data in its map of nameplates, so i was just going to piggyback. but most of what DogTag can offer really isn't all that relevant to what nameplates are supposed to do anyway, and GUID sniffing would be unwieldy at best (and most likely just impossible).
for something like a threat bar on the name plate, its going to be your threat versus your current target, and unit ids are trivially available for that relationship.
thanks for spotting that earlier post. good sanity check. saved me a bunch of time fiddling around with a stupid dead end :-)
Not a whole lot Aloft can do... essentially any addon that uses unit names as primary identifiers will have this issue. While unit frame addons can get around this by using unit IDs or GUIDs as identifiers, you can't get those data from nameplates, so it would be rather complicated for Aloft to avoid, and would require storing a bunch of additional information about every unit it encountered.
Is there any way to get Aloft to pull its mob HP info from MobInfo2 instead of mobhealth?
I use MobInfo2 for droprates and stuff anyway and both pitbull and archud pulls its mon health information from it, but aloft forces me to put in mobhealth aswell despite having another source for the information already.
You'd have to edit the code. I don't know anything about the MobInfo2 API, but there's probably only one place where Aloft does anything with MobHealth. Just figure out what the equivalent functions are for MI2 and change accordingly.
You'd have to edit the code. I don't know anything about the MobInfo2 API, but there's probably only one place where Aloft does anything with MobHealth. Just figure out what the equivalent functions are for MI2 and change accordingly.
Eeek, sounds to complicated for me :(
Guess ill have to live with the extra load unless someone with the knowhow can tell me exatly what to change and were..
(I really should learn LUA but it just looks like gibberish to me)
Is there any way to get Aloft to pull its mob HP info from MobInfo2 instead of mobhealth?
i can add this to my list of things to look into. seems like it could be an option, but of course the core Ace functionality for this (and Aloft is an Ace addon) is MobHealth, so this might need to be a line that stays drawn. MobInfo (and i use both) has always seems more like a self-updating database for feeding tooltips than a means of affecting live data display during combat, but i could be mistaken. i would have no idea of their relative merits for this purpose.
has anyone had a chance to try Aloft in the WotLK beta? is basic functionality even there?
update:
starting to get a decent handle on how to integrate LibThreat-2.0 into Aloft, and restore some threat indicator capabilities to the current version of Aloft. this is proving to be a good little project for getting familiar with the structure/flow of Aloft's codebase and runtime behavior, etc.
right now, seems to me the right approach is to model basic Aloft threat bar semantics on Aloft mana bar semantics (i.e. show only on the current target, make it as narrowly event-driven as feasible, for efficiency), and drive threat indicator updates via the same events Omen uses (Threat-2.0 callbacks, PLAYER_TARGET_CHANGED, and etc). progress has been slow (completely new tools and APIs for me, not historically a LUA developer), but there is progress :-).
the WoW 3.x threat API looks like it will have some threat-specific events that (at the moment) appear to be appropriate for this, which will be even better for 1v1 unitid-based threat tracking than the approach currently emplyed. how well the new WoW-native threat API and event model will suit group-oriented threat display and AOE-derived threat (i.e. showing everyone's threat at once relative to each other, and tracking AOE damage, stuff that current threat meters do by comprehensively sniffing the combat log) is not clear to me, but as far as "player" versus "target" is concerned, it looks "easier" to do with the new API.
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
i have used it since forever, it has continued to work with very rare little glitches through multiple WoW client patches, and i would like to keep using it. but, i have not seen an "update" for it for quite a while now, not even a 2.4.x TOC tweak.
so far, an update may not have been necessary, but... WotLK is looming, and i don't know if Aloft is going to be continued (i.e. will WotLK features subsume it and therefore render it superfluous, render it or anything like it technically infeasible, will it just keep humming along fine with a TOC tweak, or what?)
anyone have a take on this?
There haven't been any updates because the author has disappeared, and nobody else has volunteered to maintain the addon. The TOC hasn't been updated to indicate 2.4 compatibility because the addon isn't fully compatible with 2.4; it still references the now-defunct Threat-1.0, for example. I have no idea if Aloft will continue to mostly function in WotLK or not, although I suppose I'll find out soon once my beta client finishes downloading and installing.
That said, I'll test it with the LK beta when I get a chance.
Which made me hope that maybe ammo was working on a replacement of some sort. The main thing I use this mod for is to color the nameplates by class (okay well and I changed their texture and removed their border, but I can live with them not being 'pretty')
alright, understood. i don't want to "officially" volunteer, but i like the addon quite a bit, don't really see anything like it out there, and of course there are a few issues with it, so i may start fiddling with it.
on the immediate agenda would be:
- updating the tag system to use LibDogtag-3.0 (whatever the latest/greatest state-of-the-art is), assuming this is technically feasible; i gather UnitIDs are not available from nameplates, so i will have to figure this out
- updating the threat subsystem to LibThreat-2.0; i assume the same issue exists here with UnitIDs
- fixing mouse interaction (which i notice is not working for me now), assuming this is not something blizzard has broken in the underlying nameplate subsystem
any other issues Aloft users have noticed, in the way of 2.4-compatibility or broken features, feel free to mention them in this thread. i could easily smack into dead ends on lots of stuff, but i will give it a look.
i am pretty bored with the game right now anyway, marking time pending WotLK, so this might be fun. and if i can wrangle together a 2.4-compatible version of this, it probably won't be a major effort to bring it forward into WotLK as well.
i suppose with the impending refactoring of WoWAce as a mod site, i should probably distribute anything i come up with somewhere else (WoWInterface would probably be my pick, too many mod authors seem to be loosing hair over at curse). suggestions on this would also be welcome.
thanks again for the info. i will follow up here as i can.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumI would actually strongly prefer that Aloft did not use DogTag. TagCompiler is much simpler, and more importantly, does not consume more CPU cycles and increasing memory than most of my other ~150 addons combined, wheras DogTag does, even though the only addon I run which uses it is an action bar addon that uses DogTag to display key bindings (which almost never change) and item counts (which change rather infrequently in the grand scheme of things). If I could find another bar addon that covered most of what InfiniBar does, but didn't require DogTag, I would immediately dump InfiniBar.
Correct, although with WotLK looming, I'm not sure it's worth the effort, as actual threat values will now be exposed through the WoW API and will not require Threat-x.0 to estimate them.
What do you mean? Mouse interaction works fine for me.
^ I'm already using WoWInterface as my primary addon host, and now that they've got SVN repos, I'm using them for my development as well. I'm still committing "release" versions here on WowAce for updater users, but I'll probably pull them shortly so I can see what the new site has to offer before uploading again.
good point. i may deprioritize this, or code it in such a way that the choice of tag system can be selected somehow. i was not aware DogTag was... a dog? i use it several places (or the authors of the mods i use use it several places; IceHUD, CowTip, etc), and i have been accustomed to doing things with it. it just seemed natural to bring Aloft into the fold. anyway, setting it up so that either could be used could permit some benchmarking, and that would probably be the only way for me to really clarify this to myself.
i will try to dig into the new WoW-organic threat API (and maybe i can compare current and beta versions of Omen, Diamond, KLH, and etc, assuming they exist). again, perhaps, it will be easy to do it one way for the next month or two and then swap over when WotLK actually arrives. i am still looking at how Aloft collects and maintains unit data for use in nameplates, there is an elaborate lifecycle there, of which threat is just a part...
for reasons unknown to me, while native WoW nameplates permit mouse left/right-click on them for selection and interaction... Aloft nameplate frames have gone dead for me, as far as the mouse is concerned. this is under all circumstances, without regard for whether i am in combat or whatever. it could be something i have configured somehow (though actually enabling mouse interaction in Aloft, as a specific option, has no effect on this behavior). it could be synergy with another mod. i just don't know at this point. i have been looking at how Aloft believes it controls nameplate frame mouse interaction, and i expect i will need to trace it diagnostically (print out messages as the state of mouse interaction is controlled), and understand what user interface behavior i obtain relative to what Aloft believes it is doing. that will hopefully help me visualize how this is going wonky for me.
i figured that is what i would be doing, assuming i got that far. i have not tried to use any of the sites as a mod author, but i have read forum posts from authors describing general difficulty of use at curse, and lack of response getting projects approved at WoWAce, and the relative ease of use and comparatively responsive support at WoWInterface. i also use the WoWInterface automatic updater, and find it a nice feature. WoWInterface will probably be what i try first.
first i want to get deep enough into this that i can have some degree of confidence i will be adding value, before i try to set up a bunch of infrastructure.
thanks for the comments, everything like this is very helpful.
Any help please?
there is a TagCompiler RTF document, at least summarizing the syntax, distributed as part of Aloft. i have rummaged the Aloft code for various purposes over the past year or so, and have seen tags implemented that don't appear to be documented in this RTF document (like PetOwnersName), but the RTF does supply some examples and a summary of pretty much all the tags.
hope that helps.
ahh yes. i suppose i had been thinking in terms of incrementally collecting unit GUIDs, as targets were moused over, selected, and etc (and their GUIDs could be constructed)... Aloft does a fair bit of this anyway, caching a variety of different data in its map of nameplates, so i was just going to piggyback. but most of what DogTag can offer really isn't all that relevant to what nameplates are supposed to do anyway, and GUID sniffing would be unwieldy at best (and most likely just impossible).
for something like a threat bar on the name plate, its going to be your threat versus your current target, and unit ids are trivially available for that relationship.
thanks for spotting that earlier post. good sanity check. saved me a bunch of time fiddling around with a stupid dead end :-)
I have a priest called "Claw" in my guild. Whenever I'm at underbog and fight the hunter boss, his pet bear called "claw" has white bar.
I use MobInfo2 for droprates and stuff anyway and both pitbull and archud pulls its mon health information from it, but aloft forces me to put in mobhealth aswell despite having another source for the information already.
Eeek, sounds to complicated for me :(
Guess ill have to live with the extra load unless someone with the knowhow can tell me exatly what to change and were..
(I really should learn LUA but it just looks like gibberish to me)
i can add this to my list of things to look into. seems like it could be an option, but of course the core Ace functionality for this (and Aloft is an Ace addon) is MobHealth, so this might need to be a line that stays drawn. MobInfo (and i use both) has always seems more like a self-updating database for feeding tooltips than a means of affecting live data display during combat, but i could be mistaken. i would have no idea of their relative merits for this purpose.
has anyone had a chance to try Aloft in the WotLK beta? is basic functionality even there?
update:
starting to get a decent handle on how to integrate LibThreat-2.0 into Aloft, and restore some threat indicator capabilities to the current version of Aloft. this is proving to be a good little project for getting familiar with the structure/flow of Aloft's codebase and runtime behavior, etc.
right now, seems to me the right approach is to model basic Aloft threat bar semantics on Aloft mana bar semantics (i.e. show only on the current target, make it as narrowly event-driven as feasible, for efficiency), and drive threat indicator updates via the same events Omen uses (Threat-2.0 callbacks, PLAYER_TARGET_CHANGED, and etc). progress has been slow (completely new tools and APIs for me, not historically a LUA developer), but there is progress :-).
the WoW 3.x threat API looks like it will have some threat-specific events that (at the moment) appear to be appropriate for this, which will be even better for 1v1 unitid-based threat tracking than the approach currently emplyed. how well the new WoW-native threat API and event model will suit group-oriented threat display and AOE-derived threat (i.e. showing everyone's threat at once relative to each other, and tracking AOE damage, stuff that current threat meters do by comprehensively sniffing the combat log) is not clear to me, but as far as "player" versus "target" is concerned, it looks "easier" to do with the new API.