AloftCastWarning (Beta) 

yes, that is the intention.

however, there are limitations to this functionality, because Blizzard provides no way to associate nameplates with units (nameplates are basically just anonymous frames). i have to jump through some hoops to work around this (and it is not always possible to do this successfully). these limitations are detailed in README.txt (enclosed with the addon). go ahead and take a look at that, first, and relate it to what you are expecting out of the addon. make sure the addon is configured appropriately for what you want to do, etc.

in this case, you don't say anything about where you are, what you are doing, or etc, so there is no way for me to tell if you are simply encountering one of these limitations, or if there is a real problem.

if you believe there is a real problem, you will need to supply more detail, such as:

- do you have the main Aloft addon installed and enabled?
- whether you have the Blizzard "Combat>Class Colors in Nameplates" option enabled
- where you are (world/instance/arena/battlefield, etc)?
- whether you are grouped (solo/solo+pet/5-man/raid, etc)?
- what kind of unit you are hoping will display a cast bar (flagged enemy player, enemy NPC, ungrouped friendly player, grouped friendly player, your own pet, someone else's pet, etc)
- whether that unit has a raid target assignment (i.e. an icon assigned; this is a requirement for NPC targets)?
- whether you have ever moused over that unit
- whether you have ever targeted that unit
- whether a friendly group member (even just a pet) has that unit targeted

i will put these sorts of things into a FAQ for this addon, along with the information from README.txt, when i get a chance.

"quick" answer:

this is working for me, with or without my opponent active as a unitid (i was setting my opponent up as my focus target).

some clarification:

with an active unitid (like "focus"), i have to enable the "AloftCastWarning>Players" and "AloftCastWarning>Friendly Units" options, in order to see a cast warning on a "friendly player". with no active unitid (i.e. no form of targeting at all, so that the addon cannot figure out whether the unit is a player or friendly, etc, and can't filter out spell cast activity), i see a cast warning even without those options enabled.

i was also using spells the addon had "recorded" before (see below), by being cast sometime in the past by a unit with an "active unitid" (this means a unit within combat log range, while it was my own target, my focus target, or the target of a friendly group member).

so, try setting your opponent as your focus target, then target whatever you want (nothing, the pet, whatever), and have the target engage in some spell cast activity. see if you can see cast warnings that way. after that, you can drop your focus target, and try again without any form of target, using the same spells, and see if that works. the spells should be "recorded" at that point, and you should get more useful behavior out of the addon.

additional (gory) detail:

right now, looks like i have a bug; i am not "recording" spells (see below) cast by the player's current target. i don't want to show a cast warning for the player's current target (there is a "real" cast bar for that), but i do at least want to "record" any spells cast by the player's current target. this is working correctly for the player's focus target (so play around with your focus target for now). i will fix this and get a new version out in the next day or so.

so, as for the gory detail...

the combat log in the vicinity of any group of players (i.e. like in a city) is absolutely packed with junk, an incredible flood of irrelevant detail.

if the addon tried to track/display everything, you would get buried in all that irrelevant stuff (buffs, tradeskills, mount/dismount activity, everything).

as well, i am operating on the assumption that if the addon tries to invoke GetSpellInfo() on every single last thing it sees the combat log, as a prerequisite to figuring out whether it should display a cast warning for it, that could be bad too (imagine a crowded PvP situation, or a large trash mob in a raid instance... there would just tons of stuff flying through the combat log, and only a small part of it would be interesting).

so, the addon tries to filter out everything it can, and only displays stuff it "knows" is useful.

one of the things the addon does to achieve this is require that it "sees" a spell in action, first, on an active unitid (again, within combat log range, while the player's target, the player's focus target, or the target of a friendly group member), before it tries to show cast warnings for that spell. this means it has to perform a valid UnitCastingInfo() or UnitChannelingInfo() for a spell, on an active unitid, before it will display that spell as a cast warning. otherwise, it just ignores the spell (i.e. ignores that event in the combat log).

if it can make one of these calls on an active unitid and "see" the spell being cast, it will go ahead and gather GetSpellInfo() data on the spell and "record" it in its SavedVariables. from then on, once that has happened, it will display cast warnings for the spell (and it also won't need to call GetSpellInfo() on the spell again, no matter how often it sees that spell in the combat log; it can just look it up in its SavedVariables).

one of the consequences of this is that instant cast spells are not tracked (this is by design... when i first started work on this, the addon was getting swamped with activity it could never usefully present to the user). the rationale is simple: there is no reason to have a cast warning on something you cannot interrupt; use a scrolling combat text addon, or something like WitchHunt, for that sort of generalized notification.

hope all that helps. i am looking into the bug with the player's current target right now.

alright, i will experiment with this under a same-faction "duel" scenario.

i responded by editing my earlier response... take a look down there.

in short, start out by setting your opponent up as your focus target, and try things out that way. i am working on the bug i mentioned (though it looks like the bug may actually be over in Aloft... AloftCastWarning is doing some sort of garbage-in/garbage-out thing).

so, is this thing generally working for folks? have not seen too much in the way of reported bugs.

can you supply more detail?

for instance (assuming PvP in a battleground):

- are you using this in conjunction with the latest version of Aloft?
- have you read through the README.txt, and understand the way the addon works, and the limitations on its behavior?
- have you modified the options in any way (i.e. are they no longer the defaults)? if so, what have you changed?
- have you at least moused over targets with visible nameplates before expecting to see cast warnings appear for those targets?
- has the addon had time to "learn" spells, from the spellcast activity of your targets or the targets of groupmembers?

i have had some additional ideas to work around some of these limitations, but i want to gather more information/feedback before i implement any changes.

thanks.

heh, glad you like it.

new version in development that has cleaned up some stuff and is somewhat less restrictive/easier to use (tracks arena unitids, doesn't have to learn spells from targets first, will just use the combat log up front and then try to optimize from there). so, hopefully it will be even better. watch for it in a "few more days" (unfortunately all this recent downtime has slowed down my testing a bit).

yes, this is very helpful. thank you for taking the time to supply this information.

i believe the issue i quote above is the problem. a couple of aspects of the design intent for this addon were:

• to "learn" spells (store them in SavedVariables), so that the addon could avoid doing GetSpellInfo() calls every time something appeared in the combat log, and
• only "learn" spells seen on active targets (via UnitCastingInfo()/UnitChannelInfo()), so that all the useless/uninteresting junk (using bandages, for instance) that streams through the combat log as "spells" or "skills" would not end up "learned" and stored in SavedVariables.

what i think you are seeing are people using spells that the addon has not "learned" yet (the addon has not yet seen those spells being cast by units you had actively targeted), hence no cast warnings. (in development, i noticed SavedVariables for this addon growing very large during testing, several megabytes on disk, so i coded things to be very strict about what was "learned" and stored in SavedVariables.)

at this point, i think this whole approach was mistaken on my part.

i have a new version of the addon that is very close to release. this new version will go ahead and "learn" everything it sees in the combat log (regardless of its relevance... the addon has no real way to tell the difference anyway; even bandages heal, for instance), and provide a cast warning on all of it, and store what it has seen in SavedVariables when the game session ends... but on game startup it will also briefly go though and clean out any "junk" loaded from SavedVariables that does not look like a "real" spell (it will only keep the stuff that it has been able to verify using UnitCastingInfo()/UnitChannelInfo(), and that it has actually seen doing damage or healing). SavedVariables will not end up collecting a bunch of junk, and this will also recover memory at the start of each game session.

this should allow the addon to access data it has already queried the game client for (without having to query again), show cast warnings for everything without any cryptic "learning" requirement, and also avoid accumulating a large amount of irrelevant nonsense in SavedVariables.

a new version of AloftCastWarning is available, AloftCastWarning-0.7.0-1125.

this has been substantially reworked. please look at the change log for the details. hopefully you will all find that it works much "better" than in the past (and hopefully still without eating memory and CPU like candy ).

this is intended to work with Aloft-2.8.0-1127, in fact this version of Aloft is required (results with earlier versions of Aloft could be somewhat flaky).

also note that there have been enough changes in this version that you should delete your AloftCastWarning.lua SavedVariables file.