|View Bug Report|
|By: acapela - 11-27-08 11:23 AM|
alright, i can expand this to all classes. i have been in groups where people (not of normal pet-owning/summoning/controlling classes) using hotbar mods suddenly need to control another unit, and they have disabled their pet bars. so i understand the basic phenomenon.
however, if the origin unitid becomes something other than "player" in these circumstances, i will need to know that. these days, the Blizzard "GetComboPoints()" function requires an origin unitid (and Aloft is essentially hardcoding "player").
this should not affect lacerate/sunder, these parse debuffs off of "target" via the Blizzard "UnitDebuff()" function, which flags in various ways if a debuff is not owned by the querying player.
i mention this about unitid "player" because LibRoster just recently added "vehicle" to the list of unitids it handles. i am second-guessing myself here, not having a way to test things like "vehicle" (which i assume could relate to this situation in which the player mounts on some other entity, and together they become something no longer the "player") under controlled circumstances in a raid context. i don't know if "vehicle" and "player" are interchangeable in any way, or what.
so, even after i have opened this class restriction up, please observe the results and let me know whether you are seeing combo points the way you would expect to in this encounter. if not, i will have to figure out a way to detect when the player has been transformed into some sort of joint entity, and switch over to using unitid "vehicle" (or whatever) instead.
as for the other side of this relationship, the target unitid: Aloft always assumes "target" because the only nameplate Aloft can definitively identify under all circumstances is the nameplate of the player's current target (based on nameplate alpha, among all those currently visible). switching targets with latent points stacked (combo/lacerate/sunder) will pick up the current point value just fine, and display it, but display on several nameplates at once is not going to be reliable. i am guessing "target" remains valid regardless of what happens to the "player"... if a user has something targeted, the unitid "target" will be valid.