View Bug Report
AloftStackedPoints restricted to certain classes
Bug #: 5218
File: Aloft
Date: 11-27-08 10:43 AM
By: Gnarfoz
Status: Fixed
Hi there :)

There's a slight problem with restricting the AloftStackedPoints module to rogues, warriors and druids:

There's several (daily) quests and at least one raid encounter where you have to control other units or use vehicles to achieve your goal and these units or vehicles have abilities that rely on combo points.

For example, in the Malygos raid encounter, p3 has you on dragon mounts that use abilities with combo points.

Basically, just by looking at the player's class, you can't be sure he won't need combo points at some point.

The module really isn't that big and it already is a module - players who feel they don't need it (probably everyone who's not a rogue/warrior/druid + doesn't know about these quests) will disable it, anyway. No need to bail out early. ;)

Best regards

RSS 2.0 Feed for Bug CommentsNotes Sort Options
By: acapela - 11-27-08 12:23 PM
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.